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
