No, there’s no realtime patched for current kernel. such IRQ numbers is from PCI-MSI, by /proc/interrupts, it shows as IRQ is related to customized board ethernet cards. Why you think it’s related to realtime patch? Thanks.
Statistically, if someone is working with affinity, I’d say they’re likely trying to reduce latency. I didn’t know, it just brought up the possibility. The original log shows several of these:
[ 49.811245] IRQ282: set affinity failed(-22).
It does make me curious about whether the attempt to set affinity is “standard” for the driver, or if it was something specific to the Jetson? Partially I ask this because much of the hardware on a Jetson is only able to direct a hardware interrupt to the first CPU; many hardware devices (this does not apply to software drivers), if told to use a CPU other than the first CPU, will migrate back to the first CPU when they can’t reach the other CPU. Setting affinity of such a device to a non-first-CPU might either be ignored or else result in some unknown error in the kernel. Don’t know, but I do wonder about whether the affinity is trying to use an unavailable core.
Yes, normally hardware interrupt is bind to core0 by default. on my board, IRQ282 is I210 ethernet (extended ethernet port by PCIe HUB) RX-TX, its interrupt is bind to CPU0 as follows:
Also I found Xavier NX module default power mode on JP5.02 is “MODE 10W DESKTOP”, in such configuration, it will enable only 4 cores, such “set affinity failed” messages happened when kernel brings up and try to diable CPU4/CPU5.
[ 10.191497] IRQ221: set affinity failed(-22).
[ 10.191669] IRQ280: set affinity failed(-22).
[ 10.191780] IRQ281: set affinity failed(-22).
[ 10.191890] IRQ282: set affinity failed(-22).
[ 10.191992] IRQ283: set affinity failed(-22).
[ 10.192094] IRQ284: set affinity failed(-22).
[ 10.192196] IRQ285: set affinity failed(-22).
[ 10.192298] IRQ286: set affinity failed(-22).
[ 10.192400] IRQ287: set affinity failed(-22).
[ 10.192503] IRQ288: set affinity failed(-22).
[ 10.194014] CPU4: shutdown
[ 10.194404] psci: CPU4 killed (polled 0 ms)
[ 10.243597] CPU5: shutdown
[ 10.243766] psci: CPU5 killed (polled 0 ms)
If I changed power mode to “MODE 15W 6CORE”, all 6 cores will be enabled. no such irq affinity setting issue reported when kernel brings up. @WayneWWW could you help to check whether Xavier NX module will change IRQ affinity on JP5.0.2 and why? Thanks.
Looks like the nvgpu error log can be safely ignore when running shutdown command. Eventually the board will be shut down and PWR led turned off.
But trying to reboot into force-recovery mode will fail. It actually stops the reboot process and I cannot manually put the board into recovery mode.
I tried on my Jetson Xavier NX board (Carrier board made by Seeed, supposedly identical with devkit). I attached log file for shutdown and reboot case.
I don’t see any reason why a new topic is needed?
It is the same issue, this topic wasn’t closed when I post my comment, and there wasn’t any resolution.
Is there any update on this issue with nvgpu timing out during shutdown? I’ve been seeing the same thing on an AGX Xavier for a while now. This is more than a cosmetic issue for us, as we have to shut down quickly on backup power before total power loss.
Perhaps a hint at what might be happenening – in my case (power model MAXN) if i don’t run jetson_clocks at boot, nvgpu will unload cleanly at shut down.