Re: No irq handler for vector

[Johann Klammer]

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

[john doe]

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

[Johann Klammer]

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

[Sven Joachim]

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

[Brad Rogers]

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

[john doe]

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

[Brad Rogers]

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

Re: No irq handler for vector

[kamaraju kusumanchi]

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

[Henrique de Moraes Holschuh]

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

[The Wanderer]

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

[Henrique de Moraes Holschuh]

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

[kamaraju kusumanchi]

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

[The Wanderer]

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

[The Wanderer]

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

[The Wanderer]

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