[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: