Boot warnings: "No irq handler for vector …"
Hi, after updating the BIOS, I'm now met with warning/error messages every boot, however it continues to boot normally. There has since been one crash related to PCIe errors, but I'm not sure if this was related to the BIOS update or "just" a driver bug. Downgrading the BIOS to the previous version is - as I found out - not officially supported. I'm not sure how bad these warnings/errors are and if I should be concerned about it and if this should be reported to the manufacturer or kernel devs. I'd appreciate if someone more knowledgeable with this could give me an opinion on it. Relevant dmesg excerpt: [0.364305] rcu: Hierarchical SRCU implementation. [0.364572] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter. [0.364641] smp: Bringing up secondary CPUs ... [0.364641] x86: Booting SMP configuration: [0.364641] node #0, CPUs:#1 [0.068359] __common_interrupt: 1.55 No irq handler for vector [0.364641] #2 [0.068359] __common_interrupt: 2.55 No irq handler for vector [0.364705] #3 [0.068359] __common_interrupt: 3.55 No irq handler for vector [0.366814] #4 [0.068359] __common_interrupt: 4.55 No irq handler for vector [0.368708] #5 [0.068359] __common_interrupt: 5.55 No irq handler for vector [0.372703] #6 [0.068359] __common_interrupt: 6.55 No irq handler for vector [0.374847] #7 [0.068359] __common_interrupt: 7.55 No irq handler for vector [0.376706] #8 [0.068359] __common_interrupt: 8.55 No irq handler for vector [0.378863] #9 [0.068359] __common_interrupt: 9.55 No irq handler for vector [0.380706] #10 [0.068359] __common_interrupt: 10.55 No irq handler for vector [0.382816] #11 #12 #13 #14 #15 [0.394846] smp: Brought up 1 node, 16 CPUs [0.394846] smpboot: Max logical packages: 2 [0.394846] smpboot: Total of 16 processors activated (102210.65 BogoMIPS) [0.397401] devtmpfs: initialized Full dmesg logs from before and after the BIOS update are attached. Those irq errors happen with all tested kernel versions. ( Buster's 4.19.0-11-amd64, backport's 5.7.0-0.bpo.2-amd64 and local 5.8.12 and 5.8.14 kernels ) As for why I was updating the BIOS: With the previous BIOS version I wasn't able to run the RAM at the advertised speeds. Now I can, but I get these warnings/errors instead — regardless of memory speed. Nito before.log.xz Description: application/xz after.log.xz Description: application/xz
Re: No irq handler for vector
On 08/28/2020 10:10 AM, john doe wrote: > > Will need to check on the power supply, no Rugrats in my home so I'm > safe there!!! :) > I meant the people wot program the kernel. NOBODY is safe from those. >> Might also be some part of the box(GPU?) overheating. >> > > As far as I can tell, smartmontools and lm-sensors are not reporting > something out of the usual. > > You may not be able to tell. It might be a missing driver feature or undocumented OEM hardware. esp on laptops the cooling is often inadequate and to squeeze more powerful cpus into smaller cases, they often dynamically throttle down the processor speed. If that don't work, you might get interrupts trying to signal overtemperature, but with nothing there to interpret those. And lm-sensors is notoriously buggy anyway. > Any other idea(s)? > maybe chipset bugs, or some irq routing booboo. It's all guesswork on my side. > -- > John Doe
Re: No irq handler for vector
On 8/28/2020 6:35 AM, Johann Klammer wrote: On 08/27/2020 08:00 PM, john doe wrote: Debians, I just installed Debian Buster and I'm seeing the following messages at boot: "[0.005017] do_IRQ: 1.55 No irq handler for vector [0.005017] do_IRQ: 2.55 No irq handler for vector [0.005017] do_IRQ: 3.55 No irq handler for vector" I don't understand what those messages are saying. What should I do to correct whatever they are telling me? Any feedback is appriciated. -- John Doe Either an unstable power supply in your computer, or the rugrats have broken something. Will need to check on the power supply, no Rugrats in my home so I'm safe there!!! :) Might also be some part of the box(GPU?) overheating. As far as I can tell, smartmontools and lm-sensors are not reporting something out of the usual. Any other idea(s)? -- John Doe
Re: No irq handler for vector
On 08/27/2020 08:00 PM, john doe wrote: > Debians, > > I just installed Debian Buster and I'm seeing the following messages at > boot: > > > "[ 0.005017] do_IRQ: 1.55 No irq handler for vector > [0.005017] do_IRQ: 2.55 No irq handler for vector > [0.005017] do_IRQ: 3.55 No irq handler for vector" > > > I don't understand what those messages are saying. > > What should I do to correct whatever they are telling me? > > > Any feedback is appriciated. > > -- > John Doe Either an unstable power supply in your computer, or the rugrats have broken something. Might also be some part of the box(GPU?) overheating.
Re: No irq handler for vector
On 2020-08-27 19:14 +0100, Brad Rogers wrote: > On Thu, 27 Aug 2020 19:53:01 +0200 > john doe wrote: > > Hello john, > >>What should I do to correct whatever they are telling me? > > Seems to be being worked on ATM. I don't think that is actually the case, the activity in the archlinux forum notwithstanding. > See https://bbs.archlinux.org/viewtopic.php?id=256227 for some insight. There are also bugreports in Fedora and Debian: https://bugzilla.redhat.com/show_bug.cgi?id=1551605 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912085 > See > https://unix.stackexchange.com/questions/535199/how-to-deduce-the-nature-of-an-interrupt-from-its-number > for some quite detailed discussion about the issue. > > Short version - you can't do anything. _Yet_. I have been seeing these messages for several years on my laptop. The good news is that it works fine despite them, but the emergency level meant that the messages also appeared on the current terminal after resume from suspend. I installed an rsyslog filter to stop that. Cheers, Sven
Re: No irq handler for vector
On Thu, 27 Aug 2020 20:41:01 +0200 john doe wrote: Hello john, >Many thanks for the URLs and the short version! :) To be fair, my eyes started to glaze over, trying to absorb it all. I hope I got the gist of it right. >I appriciated. No problem, Jon. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" You're all invited to a party, you don't even have to come Get The Funk Out - Extreme pgpVRYmIpeEXa.pgp Description: OpenPGP digital signature
Re: No irq handler for vector
On 8/27/2020 8:14 PM, Brad Rogers wrote: On Thu, 27 Aug 2020 19:53:01 +0200 john doe wrote: Hello john, Hi there Brad, What should I do to correct whatever they are telling me? Seems to be being worked on ATM. See https://bbs.archlinux.org/viewtopic.php?id=256227 for some insight. See https://unix.stackexchange.com/questions/535199/how-to-deduce-the-nature-of-an-interrupt-from-its-number for some quite detailed discussion about the issue. Short version - you can't do anything. _Yet_. Many thanks for the URLs and the short version! :) I appriciated. -- John Doe
Re: No irq handler for vector
On Thu, 27 Aug 2020 19:53:01 +0200 john doe wrote: Hello john, >What should I do to correct whatever they are telling me? Seems to be being worked on ATM. See https://bbs.archlinux.org/viewtopic.php?id=256227 for some insight. See https://unix.stackexchange.com/questions/535199/how-to-deduce-the-nature-of-an-interrupt-from-its-number for some quite detailed discussion about the issue. Short version - you can't do anything. _Yet_. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" I hit the ground, boy have I arrived! The History Of The World (Part 1) - The Damned pgpu_AehtpZMv.pgp Description: OpenPGP digital signature
No irq handler for vector
Debians, I just installed Debian Buster and I'm seeing the following messages at boot: "[ 0.005017] do_IRQ: 1.55 No irq handler for vector [ 0.005017] do_IRQ: 2.55 No irq handler for vector [ 0.005017] do_IRQ: 3.55 No irq handler for vector" I don't understand what those messages are saying. What should I do to correct whatever they are telling me? Any feedback is appriciated. -- John Doe
Re: Buster: do_IRQ: 1.35 No irq handler for vector
Works perfectly! Thank you very much. Bruce On 3/19/19 10:37 AM, Miguel A. Vallejo wrote: I added this line as very first line in /etc/rsyslog.conf :msg, contains, "No irq handler for vector" ~ Basically it means: if message contains "No irq handler for vector" then discard. Once you add the line, restart rsyslog: systemctl restart rsyslog It's only a temporary solution until the progem gets fixed, but at least it allows you to continue doing your work. Hope this helps. Bruce Halco () wrote: Can you share what changes you made to rsyslog.conf? That's not something I've ever messed with. Thanks. Bruce
Buster alpha5 -- was Buster: do_IRQ: 1.35 No irq handler for vector
On 3/19/19 8:37 AM, Miguel A. Vallejo wrote: > It's only a temporary solution until the progem gets fixed, but at > least it allows you to continue doing your work. I installed Buster alpha5 the other day, and the LTO5 tape drive quit working, intermittently. Troubleshooting a tape drive is *slow*. It took 3 or 4 days of man pages, docs, surfing, rebooting, and some luck to discover that amanda wants a 32768 block size and tar wants 512. Settable with mt-st, when there's a tape in the drive. What is going on with the Debian management? Debian's always been solid as a rock (stable has, anyway). That tape config, the UUIDs, the s.*d word, etc. They're buggy and/or badly thought out -- their interfaces to us mortals are terrible. -- Glenn English
Re: Buster: do_IRQ: 1.35 No irq handler for vector
I added this line as very first line in /etc/rsyslog.conf :msg, contains, "No irq handler for vector" ~ Basically it means: if message contains "No irq handler for vector" then discard. Once you add the line, restart rsyslog: systemctl restart rsyslog It's only a temporary solution until the progem gets fixed, but at least it allows you to continue doing your work. Hope this helps. Bruce Halco () wrote: > > Can you share what changes you made to rsyslog.conf? That's not > something I've ever messed with. > > Thanks. > > Bruce
Re: Buster: do_IRQ: 1.35 No irq handler for vector
Can you share what changes you made to rsyslog.conf? That's not something I've ever messed with. Thanks. Bruce On 3/18/19 11:07 AM, Miguel A. Vallejo wrote: Same problem here. For me the messages appear *only* when I start the Arduino IDE and stops as soon as I close it. I suspect is something related to the pool of serial ports the Arduino IDE do to detect the plug of a new Arduino board. Adding pci=nomsi,noaer didn't work for me so I ended tweaking /etc/rsyslog.conf to get rid of them and continue to work as usual. El lun., 18 mar. 2019 a las 15:47, Bruce () escribió: I upgraded from Squeeze to Buster last week and have been having a problem with "No irq handler for vector" messages appearing in all the console windows. There were originally 3 different numeric values in the messages. After adding 'pci=nomsi,noaer' to the grub boot options, 2 of them stopped. I still get this more than 100 times per day.: Message from syslogd@penguin at Mar 18 10:11:08 ... kernel:[161132.371343] do_IRQ: 1.35 No irq handler for vector The time between messages can be as little as 9 seconds, or more than 2 hours. The messages happen throughout the day, whether I'm at the computer or not. I've tried 'dmesg -n 2', 'dmesg -n 1', and even 'dmesg -D'. The messages keep coming. I especially don't understand how 'dmesg -D' doesn't help, as it's documented purpose is to 'Disable the printing of messages to the console'. The messages don't correlate to any other events I can find in the log files. On a long shot, I disconnected the optical drives, unplugged the UPS from the USB port, and removed the TV capture card. None of that made a difference. Other than the messages, the system is running fine. The system includes a Phemon II CPU and 16 GB RAM in a Gigabyte 890GPA-UD3H motherboard. Any suggestions? Bruce
Re: Buster: do_IRQ: 1.35 No irq handler for vector
Same problem here. For me the messages appear *only* when I start the Arduino IDE and stops as soon as I close it. I suspect is something related to the pool of serial ports the Arduino IDE do to detect the plug of a new Arduino board. Adding pci=nomsi,noaer didn't work for me so I ended tweaking /etc/rsyslog.conf to get rid of them and continue to work as usual. El lun., 18 mar. 2019 a las 15:47, Bruce () escribió: > > I upgraded from Squeeze to Buster last week and have been having a > problem with "No irq handler for vector" messages appearing in all the > console windows. > > There were originally 3 different numeric values in the messages. After > adding 'pci=nomsi,noaer' to the grub boot options, 2 of them stopped. > > I still get this more than 100 times per day.: > > Message from syslogd@penguin at Mar 18 10:11:08 ... > kernel:[161132.371343] do_IRQ: 1.35 No irq handler for vector > > The time between messages can be as little as 9 seconds, or more than 2 > hours. The messages happen throughout the day, whether I'm at the > computer or not. > > I've tried 'dmesg -n 2', 'dmesg -n 1', and even 'dmesg -D'. The messages > keep coming. I especially don't understand how 'dmesg -D' doesn't help, > as it's documented purpose is to 'Disable the printing of messages to > the console'. > > The messages don't correlate to any other events I can find in the log > files. > > On a long shot, I disconnected the optical drives, unplugged the UPS > from the USB port, and removed the TV capture card. None of that made a > difference. > > Other than the messages, the system is running fine. > > The system includes a Phemon II CPU and 16 GB RAM in a Gigabyte > 890GPA-UD3H motherboard. > > Any suggestions? > > Bruce >
Buster: do_IRQ: 1.35 No irq handler for vector
I upgraded from Squeeze to Buster last week and have been having a problem with "No irq handler for vector" messages appearing in all the console windows. There were originally 3 different numeric values in the messages. After adding 'pci=nomsi,noaer' to the grub boot options, 2 of them stopped. I still get this more than 100 times per day.: Message from syslogd@penguin at Mar 18 10:11:08 ... kernel:[161132.371343] do_IRQ: 1.35 No irq handler for vector The time between messages can be as little as 9 seconds, or more than 2 hours. The messages happen throughout the day, whether I'm at the computer or not. I've tried 'dmesg -n 2', 'dmesg -n 1', and even 'dmesg -D'. The messages keep coming. I especially don't understand how 'dmesg -D' doesn't help, as it's documented purpose is to 'Disable the printing of messages to the console'. The messages don't correlate to any other events I can find in the log files. On a long shot, I disconnected the optical drives, unplugged the UPS from the USB port, and removed the TV capture card. None of that made a difference. Other than the messages, the system is running fine. The system includes a Phemon II CPU and 16 GB RAM in a Gigabyte 890GPA-UD3H motherboard. Any suggestions? Bruce
Re: No irq handler for vector
On Wed, Mar 16, 2016 at 11:35 AM, Henrique de Moraes Holschuh wrote: > On Wed, Mar 16, 2016, at 09:45, The Wanderer wrote: >> In my case, it meant that a microcode update which was/is needed on my >> combination of CPU and motherboard was not being applied. This appeared > > What processor is this, please? > Not sure if you are asking me or "The Wanderer". But here is my information. I am using Debian Stable (Jessie) rajulocal@hogwarts ~ % uname -a Linux hogwarts 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 GNU/Linux rajulocal@hogwarts ~ % cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU W3503 @ 2.40GHz stepping: 5 microcode : 0x11 cpu MHz : 2400.110 cache size : 4096 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm dtherm tpr_shadow vnmi flexpriority ept vpid bogomips: 4800.22 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU W3503 @ 2.40GHz stepping: 5 microcode : 0x11 cpu MHz : 2400.110 cache size : 4096 KB physical id : 0 siblings: 2 core id : 2 cpu cores : 2 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm dtherm tpr_shadow vnmi flexpriority ept vpid bogomips: 4800.22 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog
Re: No irq handler for vector
On Wed, 16 Mar 2016, The Wanderer wrote: > On 2016-03-16 at 11:35, Henrique de Moraes Holschuh wrote: > > On Wed, Mar 16, 2016, at 09:45, The Wanderer wrote: > > > >> In my case, it meant that a microcode update which was/is needed on > >> my combination of CPU and motherboard was not being applied. This > >> appeared > > > > What processor is this, please? > > Core i7-990X Extreme. /proc/cpuinfo reports it as: > > cpu family: 6 > model: 44 > model name: Intel(R) Core(TM) i7 CPU X 990 @ 3.47 GHz > stepping: 2 Crap. I am looking into this. > and currently (with the problem not happening) also reports > microcode: 0x14 Lucky you, 0x14 is safe enough on non-server systems. > The problem apparently only happens with some motherboards, whose BIOS > or UEFI doesn't handle something correctly (I used to know what, but > I've forgotten the details). My motherboard is an Asus Sabertooth X58, The broken IOMMU interrupt remapping on the X58/S55xx chipsets, maybe? I'd expect any BIOS with a 0x14 microcode to have the fix to the above (which is to disable the broken interrupt remapping feature of the IOMMU), so it might have been fixed when you updated that BIOS. And I *think* our 3.14 kernel eventually got the patch that bitches about BIOSes that get this wrong and tries to disable it, but I am not sure about this, so a kernel update can certainly fix it (if that's indeed the root cause of the "no irq handler for vector" on X58/S55xx systems). There was also an erratum that caused the uncore frequency multiplier to be stuck and locked on "max". This got fixed somewhere between microcode 0x10 and microcode 0x13, AFAIK... Does any of the above ring a bell? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: No irq handler for vector
On 2016-03-17 at 20:23, Henrique de Moraes Holschuh wrote: > On Wed, 16 Mar 2016, The Wanderer wrote: > >> On 2016-03-16 at 11:35, Henrique de Moraes Holschuh wrote: >>> What processor is this, please? >> >> Core i7-990X Extreme. /proc/cpuinfo reports it as: >> >> cpu family: 6 >> model: 44 >> model name: Intel(R) Core(TM) i7 CPU X 990 @ 3.47 GHz >> stepping: 2 > > Crap. I am looking into this. I'm afraid I don't quite understand. Is there still a problem worth being concerned about, now that the message has stopped appearing for me? >> and currently (with the problem not happening) also reports >> microcode: 0x14 > > Lucky you, 0x14 is safe enough on non-server systems. > >> The problem apparently only happens with some motherboards, whose >> BIOS or UEFI doesn't handle something correctly (I used to know >> what, but I've forgotten the details). My motherboard is an Asus >> Sabertooth X58, > > The broken IOMMU interrupt remapping on the X58/S55xx chipsets, > maybe? Could be. I'll try to find time tomorrow to re-do some of my previous research and dig up what I had deduced the original claimed problem to be. > I'd expect any BIOS with a 0x14 microcode to have the fix to the > above (which is to disable the broken interrupt remapping feature of > the IOMMU), so it might have been fixed when you updated that BIOS. The recurring messages persisted after the BIOS update (although they seemed, at least at first, to get less frequent), so while this may have helped, it doesn't seem to have been enough on its own. FWIW, I think the previous microcode on my system was either 0x11 or 0x10, although I can't swear to that. (I might be mixing it up with some of the computers at my workplace; I don't exactly check the BIOS on this machine very often.) It's also (at least faintly) possible that the 0x14 microcode is being put in place after boot, despite the change to stop doing that automatically. I did install iucode-tool and some other microcode-related packages in my attempts to find a fix; although it didn't seem to produce any results initially, it's not impossible that some later package update introduced a change which got the microcode being applied on-the-fly again. > And I *think* our 3.14 kernel eventually got the patch that bitches > about BIOSes that get this wrong and tries to disable it, but I am > not sure about this, so a kernel update can certainly fix it (if > that's indeed the root cause of the "no irq handler for vector" on > X58/S55xx systems). That's interesting to be aware of; thanks. Is there anything in particular I should look for, in kernel messages, to determine whether this is taking effect on my system? > There was also an erratum that caused the uncore frequency multiplier > to be stuck and locked on "max". This got fixed somewhere between > microcode 0x10 and microcode 0x13, AFAIK... > > Does any of the above ring a bell? I think it may well have been the broken interrupt remapping that was the problem, but unfortunately, it's been long enough since I gave up on the research that I don't have the details anymore. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: No irq handler for vector
On Wed, Mar 16, 2016, at 09:45, The Wanderer wrote: > In my case, it meant that a microcode update which was/is needed on my > combination of CPU and motherboard was not being applied. This appeared What processor is this, please? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh
Re: No irq handler for vector
On Wed, Mar 16, 2016 at 8:45 AM, The Wanderer wrote: > > I had this for months on end, but it stopped happening a month or two > ago. Thanks for all the information. Can you please provide the kernel version where this error does not show up. thanks raju -- Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog
Re: No irq handler for vector
On 2016-03-16 at 01:00, kamaraju kusumanchi wrote: >> From time to time, this message is printed on my konsole. > > Message from syslogd@hogwarts at Mar 16 00:12:49 ... > kernel:[1219588.659735] do_IRQ: 1.170 No irq handler for vector (irq -1) > > What does it mean? How I can rectify the problem? Is something wrong > with my hardware or is any component on my computer going bad? I had this for months on end, but it stopped happening a month or two ago. You can find mention of it by Googling on 'do_IRQ no IRQ handler for vector 1' without quotes. (Note that that's '1' rather than '-1', to accommodate Google's search syntax. Yes, this finds the right results.) In my case, it meant that a microcode update which was/is needed on my combination of CPU and motherboard was not being applied. This appeared to be because Intel decided that on-the-fly microcode updates in the way that everyone had been doing them for years were not safe, and no longer supported, on at least some CPU models - and so dropped those updates from their shipped microcode files. When the Debian package with those files and/or the tool which applies them was updated to the version which included that change, this message started appearing. The official "right" solution is apparently to update the BIOS/UEFI on your motherboard to one which deals with the issue at that level. In my case, there was no such BIOS/UEFI version available, and my motherboard is old enough that none was or is likely to be coming up. I tried various things, none of which worked, and eventually just gritted my teeth and bore with it. It doesn't seem to cause or reflect any actual functional problem, just a really severe cosmetic issue (which can cause some functional difficulties in practice, because this appears in every terminal - virtual or otherwise - on the entire system). Then, a couple of months back, it stopped happening. I do not know what caused the change, but in current Debian testing, it does not happen for me anymore. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: No irq handler for vector
On 2016-03-16 at 11:35, Henrique de Moraes Holschuh wrote: > On Wed, Mar 16, 2016, at 09:45, The Wanderer wrote: > >> In my case, it meant that a microcode update which was/is needed on >> my combination of CPU and motherboard was not being applied. This >> appeared > > What processor is this, please? Core i7-990X Extreme. /proc/cpuinfo reports it as: cpu family: 6 model: 44 model name: Intel(R) Core(TM) i7 CPU X 990 @ 3.47 GHz stepping: 2 and currently (with the problem not happening) also reports microcode: 0x14 The problem apparently only happens with some motherboards, whose BIOS or UEFI doesn't handle something correctly (I used to know what, but I've forgotten the details). My motherboard is an Asus Sabertooth X58, running (AFAICT) the latest available BIOS for that model; I don't have any identifying details which seem more useful than that. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: No irq handler for vector
On 2016-03-16 at 23:30, kamaraju kusumanchi wrote: > On Wed, Mar 16, 2016 at 8:45 AM, The Wanderer > wrote: > >> I had this for months on end, but it stopped happening a month or >> two ago. > > Thanks for all the information. Can you please provide the kernel > version where this error does not show up. I don't think the kernel would be related to this, but I'm currently running 4.3.0-1-amd64. (The installed linux-image-4.3.0-1-amd64 package version is 4.3.5-1, but I haven't rebooted in well over two months, so it's plausible that I may still be running 4.3.0 itself.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
No irq handler for vector
>From time to time, this message is printed on my konsole. Message from syslogd@hogwarts at Mar 16 00:12:49 ... kernel:[1219588.659735] do_IRQ: 1.170 No irq handler for vector (irq -1) What does it mean? How I can rectify the problem? Is something wrong with my hardware or is any component on my computer going bad? thanks raju -- Kamaraju S Kusumanchi | http://raju.shoutwiki.com/wiki/Blog