On Tue, Oct 08, 2013 at 10:45:32PM +0200, Jean Delvare wrote: > Hi Greg, hi Neil, > > Le Tuesday 23 July 2013 à 10:06 -0700, Greg KH a écrit : > > On Mon, Jul 08, 2013 at 01:06:14PM -0400, Neil Horman wrote: > > > A few years back intel published a spec update: > > > http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf > > > > > > For the 5520 and 5500 chipsets which contained an errata (specificially errata > > > 53), which noted that these chipsets can't properly do interrupt remapping, and > > > as a result the recommend that interrupt remapping be disabled in bios. While > > > many vendors have a bios update to do exactly that, not all do, and of course > > > not all users update their bios to a level that corrects the problem. As a > > > result, occasionally interrupts can arrive at a cpu even after affinity for that > > > interrupt has be moved, leading to lost or spurrious interrupts (usually > > > characterized by the message: > > > kernel: do_IRQ: 7.71 No irq handler for vector (irq -1) > > > > > > There have been several incidents recently of people seeing this error, and > > > investigation has shown that they have system for which their BIOS level is such > > > that this feature was not properly turned off. As such, it would be good to > > > give them a reminder that their systems are vulnurable to this problem. For > > > details of those that reported the problem, please see: > > > https://bugzilla.redhat.com/show_bug.cgi?id=887006 > > > > > > [ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ] > > > > > > Notes: Modified early-quirks.c to include linux/irq.h, to fix warnings. This > > > isn't needed in the upstream tree > > > > > > Signed-off-by: Neil Horman <nhorman@xxxxxxxxxxxxx> > > > CC: Prarit Bhargava <prarit@xxxxxxxxxx> > > > CC: Don Zickus <dzickus@xxxxxxxxxx> > > > CC: Don Dutile <ddutile@xxxxxxxxxx> > > > CC: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > > > CC: Asit Mallick <asit.k.mallick@xxxxxxxxx> > > > CC: David Woodhouse <dwmw2@xxxxxxxxxxxxx> > > > CC: linux-pci@xxxxxxxxxxxxxxx > > > CC: Joerg Roedel <joro@xxxxxxxxxx> > > > CC: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > > > CC: Arkadiusz Miśkiewicz <arekm@xxxxxxxx> > > > CC: Jean Delvare <jdelvare@xxxxxxx> > > > CC: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > > > Signed-off-by: Joerg Roedel <joro@xxxxxxxxxx> > > > (cherry picked from commit 03bbcb2e7e292838bb0244f5a7816d194c911d62) > > > > As 3.9-stable is now dead, this one missed that window, sorry about > > that. > > Sorry for jumping in a little late, but I am looking into this again > because one customer of ours requested this fix. I'm a bit confused now, > by two different things: > > 1* Why did Greg claim that the fix missed the 3.9-stable window while I > can see Neil's backport of the fix made it into 3.9.9? Greg doesn't remember what patches he applied to what stable tree, nor if he had applied them to a previous stable release at all. His short-term memory is almost non-existant given the huge rate of patches flowing through him, and he is feeling strange referring to himself in the third person... > 2* Why was the backport only added to 3.9-stable and not also > 3.4-longterm and 3.0 longterm? Probably because the patch sent to me didn't apply there? > I need the fix for the SLE11 SP3 kernel which is based on 3.0. Neil, do > you have a backport of the fix for this kernel? The 3.9 doesn't apply :( Ah, yes, that's why I didn't apply it. If someone sends me a version that does, I will add it to those trees. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
