lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 2 Mar 2013 15:13:56 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	linux-kernel@...r.kernel.org, Don Zickus <dzickus@...hat.com>,
	Don Dutile <ddutile@...hat.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Asit Mallick <asit.k.mallick@...el.com>,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH] irq: add quirk for broken interrupt remapping on 55XX
 chipsets

On Sat, Mar 02, 2013 at 11:21:29AM -0500, Prarit Bhargava wrote:
> On 03/01/2013 12:17 PM, 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.
> > 
> > Signed-off-by: Neil Horman <nhorman@...driver.com>
> > CC: Prarit Bhargava <prarit@...hat.com>
> > CC: Don Zickus <dzickus@...hat.com>
> > CC: Don Dutile <ddutile@...hat.com>
> > CC: Bjorn Helgaas <bhelgaas@...gle.com>
> > CC: Asit Mallick <asit.k.mallick@...el.com>
> > CC: linux-pci@...r.kernel.org
> > ---
> >  drivers/iommu/intel_irq_remapping.c | 20 ++++++++++++++++++++
> >  include/linux/pci_ids.h             |  2 ++
> >  2 files changed, 22 insertions(+)
> > 
> > diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c
> > index f3b8f23..9bfb6c2 100644
> > --- a/drivers/iommu/intel_irq_remapping.c
> > +++ b/drivers/iommu/intel_irq_remapping.c
> > @@ -1113,3 +1113,23 @@ struct irq_remap_ops intel_irq_remap_ops = {
> >  	.msi_setup_irq		= intel_msi_setup_irq,
> >  	.setup_hpet_msi		= intel_setup_hpet_msi,
> >  };
> > +
> > +
> > +static void intel_remapping_check(struct pci_dev *dev)
> > +{
> > +	u8 revision;
> > +
> > +	pci_read_config_byte(dev, PCI_REVISION_ID, &revision);
> > +
> > +	if ((revision == 0x13) && irq_remapping_enabled) {
> > +		pr_warn("WARNING WARNING WARNING WARNING WARNING WARNING\n"
> > +			"This system BIOS has enabled interrupt remapping\n"
> > +			"on a chipset that contains an errata making that\n"
> > +			"feature unstable.  Please reboot with nointremap\n"
> > +			"added to the kernel command line and contact\n"
> > +			"your BIOS vendor for an update");
> 
> Make this one line?  Might be too long but I believe the preferred policy is now
> to keep the output on one line so that it is easy to find in the kernel source.
> 
> Also, IMO, remove the WARNING WARNING stuff.
> 
> You also should probably use HW_ERR here too.
> 
> P.
> 
I can do that, I'll post version 2 on monday.
Neil

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ