AMD ошибки после обновления BIOS
Мать MSI MPG X570 gaming plus, процессор Ryzen7 3700X, Fedora 32, ядро 5.6.19-300. Обновил только что BIOS с исправлениями уязвимости в UEFI, при загрузке сыпятся ошибки, я так понял при инициализации каждого ядра
но система в итоге загружается и всё работает. Кто-нибудь сталкивался/поборол подобное?
на АМД проблем небывает
так это не проблема
всё работает, здесь не на что смотреть, расходитесь
было такое в арч и на сиде с ядрами 5.0 — 5.4, но потом проблема исчезла — видать починили…
Эта проблема не связана с UEFI, по крайней мере напрямую. Тег можно убрать (но развидеть это я уже не смогу ☹).
Спасибо, Кэп. А на офсайте материнки в разделе BIOS образ чего я скачал?
Эта проблема не связана с UEFI, по крайней мере напрямую.
Компания AMD сообщила о работе над исправлением серии уязвимостей «SMM Callout» (CVE-2020-12890), позволяющей получить контроль над прошивкой UEFI и выполнить код на уровне SMM (System Management Mode).
Компания AMD уже передала большинству производителей материнских плат обновление прошивки с исправлением проблемы.
Компания AMD сообщила о работе над исправлением серии уязвимостей «SMM Callout» (CVE-2020-12890), позволяющей получить контроль над прошивкой UEFI и выполнить код на уровне SMM (System Management Mode).
И какое отношение имеет тег UEFI к твоим проблемам в ядре? Это проблемы ядра Linux с линейкой Ryzen, и UEFI здесь совершенно не причём.
Ты меня кастанул тегом, я копетаню.
Тем более у тебя в тегах и UEFI и BIOS.
Тупые маркетолухи смешали всё, теперь все юзеры, даже если они не совсем тупые, попугайствуют эту кашу. >_<
И какое отношение имеет тег UEFI к твоим проблемам в ядре? Это проблемы ядра Linux с линейкой Ryzen, и UEFI здесь совершенно не причём.
Я пользуюсь Ryzen уже пол-года и ни с одним ядром не было никаких проблем, в том числе и с тем что у меня сейчас. Проблема возникла именно после обновления UEFI.
Вот, кстати, что на буржуинских багтрекерах пишут по этому поводу…
As you can see in the dmesg log it happens when the kernel is initializing the second CPU core. I believe this started after the AMD microcode update against Spectre/Meltdown mitigations.
Подожду следующего ядра, короче…
А у меня вот такие сообщения постоянно лезут, ничего с ними сделать не могу. Вроде все работает, но логи засраны, бесит.
Обновлений фирмвари на плату не выпускали с 2019 года, хотя она все еще в списке поддерживаемых.
Arch Linux
From what I can tell, this is an "emergency" level item, so setting the loglevel kernel parameter doesn't fix this (and I can't imagine it's good practice to hide emergency level items in any case).
I don't think it's causing any particular issues on my system as I can boot in fine but I would like to get to the bottom of this.
I've seen a couple of posts on this forum with a similar issue but the one marked [solved] suggested using "acpi=noirq" as a kernel parameter. I tried that and it didn't change the outcome.
Some relevant information about my system:
Any tips on how to resolve this would be greatly appreciated.
#2 2020-06-03 21:31:34
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
I've tried to do some more digging on this but not sure if I'm getting anywhere.
Based on a particular google result, I recompiled the kernel with the "CONFIG_GENERIC_IRQ_DEBUGFS" kernel option enabled (first time doing that so good learning experience!) and then searched the debugfs for this particular vector:
No mention of Vector 55. No idea where to go from here. Does anyone have any ideas?
Interestingly, I don't get this message on Xubuntu 16.04 (the old HTPC os I'm using) — can't recall off-hand which kernel version it's on.
#3 2020-06-03 22:28:52
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
Does adding the kernel parameter nomsi have any effect?
#4 2020-06-04 05:25:38
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
Does adding the kernel parameter nomsi have any effect?
Thanks loqs. I assume you mean:
which I saw in a couple of posts. If so, yes, I tried it as I had a similar line my lspci (see bottom of this post) and it didn't stop the error message.
I tried it before the custom kernel so I've just retried it again to see if there was any change to the irqs outputs. The main difference was that it reduced the number of them:
dmesg output from this boot: http://ix.io/2oeD
Here's the lspci output (when booting with pci=nomsi) which shows the similar lines to the post suggesting this as a fix:
A couple of differences to that post, my board isn't using a VIA chipset and I have the line:
where they have
I don't know how important the +/- is after the Enable.
#5 2020-06-05 07:49:08
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
I've also tried latest linux kernel (5.6.15.arch1-1) but still get the same message.
In terms of debugging this, is it worth unplugging devices (USB devices, TV Tuner PCI card) to see if that stops the messages and, if so, reconnecting one by one to see which triggers this error?
On the plus side, it doesn't seem to cause any issue to my system so far although, admittedly, it's not doing much at the moment (just booting to login prompt) as I'm gradually installing the bits I need for the HTPC.
#6 2020-06-05 16:57:11
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
For those that are interested in this, I found a thread on the Linux kernel mailing list about this issue. The error seems to arise when a multiple CPU cores are initalised (in my case, the 1 before the .55 is for the second core). Sadly the majority of the discussion in that thread is way beyond my understanding but the general gist seems to be that this is a harmless message due to some AMD or BIOS issue.
Interestingly, I don't get this message on Xubuntu 16.04 (the old HTPC os I'm using) — can't recall off-hand which kernel version it's on.
Turns out, this isn't quite true. From another thread on LKML it looks like the error was previously reported as
and, indeed, if I search dmesg on my HTPC (on Xubuntu 16.04 kernel: 4.4.0-131-generic #157-Ubuntu) I do have that exact line
Interestingly, that message is loglevel 7 on 4.4.0-131
but is now loglevel 0 on latest kernels. That's quite an escalation.
So, I suspect there's no quick fix for the message and it's safe to ignore. I'd just prefer not to see it at all.
EDIT: Apologies — just realised, I should have edited previous post rather than post this as new one.
Last edited by elParaguayo (2020-06-05 16:57:54)
#7 2020-06-05 18:13:15
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
You could try the proposed patch from https://lkml.org/lkml/2019/3/7/212
#8 2020-06-05 18:13:21
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
There is an F5 version available, but i doubt it will help.
#9 2020-06-05 18:37:19
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
You could try the proposed patch from https://lkml.org/lkml/2019/3/7/212
Yes, although that post says the patch didn't work so I wouldn't hold out much hope. Also, it took about 5 hours to compile the kernel last time so I'm not desperate to do it again but no harm in trying.
There is an F5 version available, but i doubt it will help.
I doubt it too! It's about 9 years old and this issue is still around. I'm also not desperate to update the BIOS unless I really have to.
#10 2020-06-05 18:44:38
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
Also, it took about 5 hours to compile the kernel last time so I'm not desperate to do it again but no harm in trying.
Have you enabled parallel compilation? To reduce the compile time?
#11 2020-06-05 19:26:45
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
Also, it took about 5 hours to compile the kernel last time so I'm not desperate to do it again but no harm in trying.
Have you enabled parallel compilation? To reduce the compile time?
Sadly, yes. I used the nproc line from that link. Not sure how long it would have taken without it.
It's fine, I can always leave it running overnight.
#12 2020-06-06 09:10:26
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
Well, this compiled much quicker than last time (I just changed the file in the source folder and rebuilt with makepkg (using —noextract)).
The message was still there on boot.
I can hide it if I change loglevel kernel parameter to 0 but that, for some reason, stops plymouth working (when the error message was on the screen, you could see the resolution change before plymouth started but that's not happening now). I'll have a little play with the parameters but may start a new thread on that.
However, for this particular issue, it feels like we've gone as far as we can. Appreciate the support.
#13 2020-06-06 14:13:34
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
You could contact upstream see if they have any other suggestions for resolving the issue in the kernel or if it is just considered a firmware bug.
#14 2020-06-24 12:06:10
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
Although I am a Manjaro user I want to mention here that just today this issue popped up with the BIOS upgrade that I did today. I installed new beta BIOS 7C37v193(Beta version) for my MSI MPG X570 GAMING EDGE WIFI board. I did not have any errors or issues with the previous beta 7C37v192(Beta version) which I was running for several weeks now.
This new BIOS 7C37v193(Beta version) is coming with "Updated AMD AGESA ComboAm4v2PI 1.0.0.2" as the only change and the messages I get with that are:
I seee this with kernel 5.4.48 and 5.7.5 with a Ryzen 7 3700X.
kernel command line parameter "pci=nomsi,noaer" does not help. It is not booting with nomsi and noaer alone makes no difference.
#15 2020-06-24 20:40:53
Re: Error message during boot: do_IRQ: 1.55 No irq handler for vector
Although I am a Manjaro user I want to mention here that just today this issue popped up with the BIOS upgrade that I did today. I installed new beta BIOS 7C37v193(Beta version) for my MSI MPG X570 GAMING EDGE WIFI board. I did not have any errors or issues with the previous beta 7C37v192(Beta version) which I was running for several weeks now.
This new BIOS 7C37v193(Beta version) is coming with "Updated AMD AGESA ComboAm4v2PI 1.0.0.2" as the only change and the messages I get with that are:
I seee this with kernel 5.4.48 and 5.7.5 with a Ryzen 7 3700X.
kernel command line parameter "pci=nomsi,noaer" does not help. It is not booting with nomsi and noaer alone makes no difference.
Don't mean to hijack the thread, but I just updated bios on my MSI x570 MB (with Ryzen 3800X) to version 7C35v196(beta) and started to get the same errors (was running previous beta for a couple of weeks without this error present, but with random crashes due to mce microcode errors and thought that I would try this new version).
Error No iqr handler for vector
Sorry for my bad English, I’ve a problem during the boot of Ubuntu 18.04 Bionic Beaver.
When I boot the first option of the grub «Ubuntu», a black screen appears and
Or something like that and takes a long time to start the OS, then I can perfectly use it, my laptop is a Lenovo G50-45. I have had problems with the privative drivers, really I’m a newbie in Linux, but this problem makes me annoying.
If you have a link in this forum o another please share me the results or if you know how to resolve it, IDK please.
Debian User Forums
[SOLVED] Error msg in terminal: "No irq handler for vector"
[SOLVED] Error msg in terminal: "No irq handler for vector"
#1 Post by robgeek » 2013-07-19 23:12
Re: Big problem with Debian kernel.
#2 Post by bw123 » 2013-07-19 23:35
Re: Big problem with Debian kernel.
#3 Post by robgeek » 2013-07-20 00:28
Advanced
PCIPnP
Plug & Play O/S’ [No]
Resources Controlled By [AUTO]
*IRQ Resources «nothing here, and the color of this option is gray.»
Assign IRQ For VGA [DISABLED] «Like you said to do.»
** PCI Express relative itens **
Maximum Payload Size [409 6]
Re: Big problem with Debian kernel.
#4 Post by robgeek » 2013-07-20 15:01
Re: Big problem with Debian kernel.
#5 Post by cynwulf » 2013-07-20 15:41
No need to mess with BIOS settings. I searched duckduckgo for «No irq handler for vector (irq -1)» and came up with a few useful results.
Re: Big problem with Debian kernel.
#6 Post by robgeek » 2013-07-20 18:17
It seems to me that i have to add «pci=nomsi,noaer» into the boot code, but where is «syslinux.cfg» file?
How can i do that?
Re: Big problem with Debian kernel.
#7 Post by robgeek » 2013-07-22 16:02
Re: Big problem with Debian kernel.
#8 Post by cynwulf » 2013-07-22 20:16
Re: Big problem with Debian kernel.
#9 Post by robgeek » 2013-07-22 22:16
Re: Big problem with Debian kernel.
#10 Post by Randicus » 2013-07-22 22:32
Re: Big problem with Debian kernel.
#11 Post by robgeek » 2013-07-24 17:24
Re: Big problem with Debian kernel.
#12 Post by cynwulf » 2013-07-25 08:06
You don’t need to worry about syslinux.
Just boot the system, when the grub menu appears hit the letter ‘e’ to edit the line
Move the cursor to the end of the line (usually after «ro») and type the options «pci=nomsi,noaer», without the quotes, there.
Then do CTRL+x to boot from that kernel. If that does the trick you can look into doing a permanent edit to the grub configuration.
Re: Big problem with Debian kernel.
#13 Post by fsmithred » 2013-07-25 09:23
Re: Big problem with Debian kernel.
#14 Post by robgeek » 2013-07-26 19:30
Guys. Problem fixed! Thank you very, very much!
After 3 years with this annoying problem finally he wont piss me off again.
I oppened /etc/default/grub and i added ( pci=nomsi,noaer ) between the quote marks in GRUB_CMDLINE_LINUX=»» line.
And finally, in terminal: update-grub
Well, actually i have no idea what i did, but it worked.
Re: [SOLVED] Error msg in terminal: "No irq handler for vect
#15 Post by Tom Booth » 2018-11-12 03:34
Isn’t that kind of like disconnecting the «Check Engine» light. noaer — translation: No advanced error reporting.
Anyway, I get the same, or similar «No IRQ handler for vector» error every time I boot up ANY Linux distro. I’m using Easy2Boot mutiboot from USBs.
There is a pause at this error, often for quite a long time, then the boot will eventually continue successfully. It is only slightly annoying. Mostly I was just wondering what might be causing it and if there might be some cure, Just to speed up boot time if nothing else, it seems to cause a substantial delay.