Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #165462 > unrolled thread

No irq handler for vector

Back to article view | Back to linux.debian.user

Contents

  No irq handler for vector kamaraju kusumanchi <raju.mailinglists@gmail.com> - 2016-03-16 06:10 +0100
    Re: No irq handler for vector The Wanderer <wanderer@fastmail.fm> - 2016-03-16 13:50 +0100
      Re: No irq handler for vector Henrique de Moraes Holschuh <hmh@debian.org> - 2016-03-16 16:40 +0100
        Re: No irq handler for vector The Wanderer <wanderer@fastmail.fm> - 2016-03-17 04:00 +0100
          Re: No irq handler for vector Henrique de Moraes Holschuh <hmh@debian.org> - 2016-03-18 01:30 +0100
            Re: No irq handler for vector The Wanderer <wanderer@fastmail.fm> - 2016-03-18 04:30 +0100
        Re: No irq handler for vector kamaraju kusumanchi <raju.mailinglists@gmail.com> - 2016-03-17 04:30 +0100
      Re: No irq handler for vector kamaraju kusumanchi <raju.mailinglists@gmail.com> - 2016-03-17 04:40 +0100
        Re: No irq handler for vector The Wanderer <wanderer@fastmail.fm> - 2016-03-17 13:50 +0100

#165462 — 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

[toc] | [next] | [standalone]

#165471

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#165485

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 <hmh@debian.org>

[toc] | [prev] | [next] | [standalone]

#165516

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#165564

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

[toc] | [prev] | [next] | [standalone]

#165566

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#165517

On Wed, Mar 16, 2016 at 11:35 AM, Henrique de Moraes Holschuh
<hmh@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#165518

On Wed, Mar 16, 2016 at 8:45 AM, The Wanderer <wanderer@fastmail.fm> 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

[toc] | [prev] | [next] | [standalone]

#165526

[Multipart message — attachments visible in raw view] — view raw

On 2016-03-16 at 23:30, kamaraju kusumanchi wrote:

> On Wed, Mar 16, 2016 at 8:45 AM, The Wanderer <wanderer@fastmail.fm>
> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web