Boot frozen. 55 no irq handler for vector

Sorry if this was addressed already, but I’ve been looking for a wile.
I just downloaded manjaro plasma last night. (15AUG20)
Haven’t had any problems, other then the error:

Everything was running fine with that being said.
Download a game and discord. No problems.
Then I restarted the computer and it froze on that screen. It won’t let me type and all I can do is restart. But it just goes right back to that screen.

Sorry in advanced, I’m new to Linux.

1 Like

Yes this was asked before, but not on the new forum :wink:

This and this will likely give you the answers you need.

Welcome to the forum and the community :smiley:

I had a similar error after a BIOS upgrade:

For me there was no other solution but to downgrade the BIOS.

1 Like

Thank you for the link!

Thats frustrating but helpful. I appreciate the quick responses.

So I tried the second, and I made it work, but the error was still in the background.
And looking at the 1st… all its saying is to go with an old kernel… (unless I misunderstood)
I’m going through the tutorial they suggested on downloading architect for a custom boot. Do you know/have you heard of a fix with the newest kernel? Or am I stuck going with on old one to fix the problem?

Yeah I faintly remember having read something about a fix somewhere. Can atleast not hurt to try the 5.8 Kernel. Gonna have to look if i can find the news again where i read it.

I’d appreciate that. And I’m using the 4.9 and the latest kernel. Didn’t realise you could use both. Hopefully that helps.

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

2 Likes

this coming from this change

i’d love to get rid of this. it’s showing on boot, resume, shutdown… slap in my face so many times, with kernel 5.4,5.5,5.6,5.7,5.8,5.9. the ancient advices don’t make a change. how come *ubuntu distros nicely hide it and show vendor logo instead?

update
from the chefs menu: pci=nomsi, pci=noaer, acpi=noirq, acpi=ht, nolapic, noapic, pnpacpi=off, pci=noacpi, irqpoll
all caused X not to load. but with logo or empty screen.
except noapic which loaded SDDM but made suspend hard reset worthy.
rellocating PCI card (to bump GFX 8 lanes to 16 lanes) didn’t help.
so still no solution. tested kde neon,kubuntu today and they hide it.

what helps is loglevel=0

meanwhile i analysed distros

  1. is live boot with nvidia drivers included?

  2. is the screen corrupted when booting ISO? (uninstallable)

  3. after installed, nvidia installed too, is the boot screen nice (e.g. vendor logo)?

  4. does the boot screen leak IRQ errors?

    mint - no yes yes no

    manjaro - yes no no yes

    arcolinux - yes no no yes

    endeavor - yes no no yes

    opensuse - no no yes yes

    pop!os - yes no yes no

    pclinuxos - yes no yes yes

    fedora - no no yes yes

    kubuntu - no yes yes no

    ubuntu - no yes yes no

    neon - no yes yes no

    mx linux - yes no no yes

    solus - no yes ? ? (no safe mode - not installable)

so the ubuntu derivatives are terrible to install, only in safe mode, but they hide the ugly errors almost perfectly. rpm distros don’t pack nvidia drivers, but have absolutely no problem booting live, and show nice boot screen when installed. but leak some IRQ errors for few seconds. archs pack nvidia, so they install well too, but don’t bother with boot screen much, so they also leak IRQ errors.

and which distros have nvidia related problems at runtime, like blackscreen, emptied windows etc? ALL. Additionally, ubuntu derivatives have invisible sddm issue (only mouse moving on whatever is rendered at the moment).

That’s a ton of research you did… ty for that very interesting post…
Just updated to latest gigabyte bios on my 570 and kernel 5.9 still same problem…

How much does loglevel=0 help and where do I put it

The error doesn’t bother me as much as having to wait like an extra 20 seconds every time I boot

--------> @Mawschwitz

Machine:
ASUS TUF GAMING B550-PLUS / Ryzen 7 3700X /Manjaro Gnome (testing)

GRUB-Boot-Parameter add “noapic acpi=noirq

Results in: no more this message.
computing power unchanged, Sensor perception: everything o.K.

_--------------------------------------------------------
Berlin Tea-Party NOW!

1 Like