Hi, Mawschitz,
My system is based on Gigabyte-MB with X570 Chipset , Ryzen 3600 and I run an Ubuntu with 5.7.13 and an Arch Linux with 5.8.3
After AGESA-Update I also got the same “irq-handler” message.
I did some investigation…
First searching for vector “55” in the irq-table:
The command
# grep 55 /sys/kernel/debug/irq/irqs/*
got no result.
So the vector 55 is announced by BIOS, but not really in use.
according to lore.kernel.org/linux-pci/87imkr4s7n.fsf@nanos.tec.linutronix.de/
#1 1) If the new vector is not in use on the local CPU and the device affected by the affinity change raised an interrupt during the transitional state (step #1 above) then interrupt entry code will gnore that spurious interrupt. The vector is marked so that the ‘No irq handler for vector’ warning is supressed once.
…
#1 is uninteresting and has no unintended side effects. #2 and #3 might expose issues in device driver interrupt handlers which are not prepared to handle a spurious interrupt correctly. This not a regression, it’s just exposing something which was already broken as spurious interrupts can happen for a lot of reasons and all driver handlers need to be able to deal with them.
I looked at the lines in dmesg:
smp: Bringing up secondary CPUs ...
x86: Booting SMP configuration:
.... node #0, CPUs: #1
do_IRQ: 1.55 No irq handler for vector
#2
do_IRQ: 2.55 No irq handler for vector
#3
do_IRQ: 3.55 No irq handler for vector
#4
do_IRQ: 4.55 No irq handler for vector
and so on…
On my system the irq-handler is adressing not the core #0, but all following cores.
There is no
do_IRQ: 0.55 No irq handler for vector
-message…
So I think, that is the impact the of
“The vector is marked so that the ‘No irq handler for vector’ warning is supressed once.”
and so I am convinced here is the situation of
#1 is uninteresting and has no unintended side effects.
…
But this is just my personal perspective and my humble opinion and I am far away from persuading people.
I just wanna give my opinion to a critical review…
Kindly regards,
zimmet