Yes this was asked before, but not on the new forum 
This and this will likely give you the answers you need.
Welcome to the forum and the community 
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
-
is live boot with nvidia drivers included?
-
is the screen corrupted when booting ISO? (uninstallable)
-
after installed, nvidia installed too, is the boot screen nice (e.g. vendor logo)?
-
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).
1 Like
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
What BIOS version are you running I noticed this error happen after I updated my BIOS
Did you update your bios along with adding the GRUB boot parameter or you simply added the GRUB boot parameter
Where did you put the GRUB boot parameter
What kernel are you running?
Edit as root:
/etc/default/grub.conf
Example (on my machine):
GRUB_CMDLINE_LINUX_DEFAULT=“quiet acpi_enforce_resources=lax noapic apparmor=1 security=apparmor udev.log_priority=3”
Thank you for trying to help out
sudo nano /etc/default/grub
(i did not find a /etc/default/grub.conf file)
GRUB_CMDLINE_LINUX_DEFAULT=“quiet noapic acpi=noirq apparmor=1 security=apparmor udev.log_priority=3”
This didnt fix anything and i still get the IRQ Handler for Vector error,
i can still use the computer perfectly fine it just stays stuck in that boot screen for like 30 seconds before booting
i read here they recommend pci=nomsi,noaer instead of noapic acpi=noirq care to comment?
Just try, but carefully, only by editing Grub-menu.
On an old machine for example “noapic” leads to infinite reboot-loop, so that I must stop this with the mains switch…
Other possibilities:
acpi=noirq only
noapic only
pci=noapic
I just updated to kernel 5.9 latest and the problem is fixed!!!
3 Likes