aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pci
diff options
context:
space:
mode:
authorSuresh Siddha <suresh.b.siddha@intel.com>2010-12-06 15:26:30 -0500
committerH. Peter Anvin <hpa@linux.intel.com>2010-12-13 19:51:51 -0500
commit254e42006c893f45bca48f313536fcba12206418 (patch)
tree4eed3ddc7c186dc7cb6087824132c8f95d032fb1 /drivers/pci
parent10340ae130fb70352eae1ae8a00b7906d91bf166 (diff)
x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic
On platforms with Intel 7500 chipset, there were some reports of system hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled. During kdump, there is a window where the devices might be still using old kernel's interrupt information, while the kdump kernel is coming up. This can cause vt-d faults as the interrupt configuration from the old kernel map to null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled, we still have the same issue but in this case we will see benign spurious interrupt hit the new kernel). Based on platform config settings, these platforms seem to generate NMI/SMI when a vt-d fault happens and there were reports that the resulting SMI causes the system to hang. Fix it by masking vt-d spec defined errors to platform error reporting logic. VT-d spec related errors are already handled by the VT-d OS code, so need to report the same error through other channels. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com> Cc: stable@kernel.org [v2.6.32+] Reported-by: Max Asbock <masbock@linux.vnet.ibm.com> Reported-and-tested-by: Takao Indoh <indou.takao@jp.fujitsu.com> Acked-by: Chris Wright <chrisw@sous-sol.org> Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Diffstat (limited to 'drivers/pci')
-rw-r--r--drivers/pci/quirks.c23
1 files changed, 23 insertions, 0 deletions
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 6f9350cabbd5..36191edd6d51 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2764,6 +2764,29 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_m
2764DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832); 2764DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);
2765#endif /*CONFIG_MMC_RICOH_MMC*/ 2765#endif /*CONFIG_MMC_RICOH_MMC*/
2766 2766
2767#if defined(CONFIG_DMAR) || defined(CONFIG_INTR_REMAP)
2768#define VTUNCERRMSK_REG 0x1ac
2769#define VTD_MSK_SPEC_ERRORS (1 << 31)
2770/*
2771 * This is a quirk for masking vt-d spec defined errors to platform error
2772 * handling logic. With out this, platforms using Intel 7500, 5500 chipsets
2773 * (and the derivative chipsets like X58 etc) seem to generate NMI/SMI (based
2774 * on the RAS config settings of the platform) when a vt-d fault happens.
2775 * The resulting SMI caused the system to hang.
2776 *
2777 * VT-d spec related errors are already handled by the VT-d OS code, so no
2778 * need to report the same error through other channels.
2779 */
2780static void vtd_mask_spec_errors(struct pci_dev *dev)
2781{
2782 u32 word;
2783
2784 pci_read_config_dword(dev, VTUNCERRMSK_REG, &word);
2785 pci_write_config_dword(dev, VTUNCERRMSK_REG, word | VTD_MSK_SPEC_ERRORS);
2786}
2787DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x342e, vtd_mask_spec_errors);
2788DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x3c28, vtd_mask_spec_errors);
2789#endif
2767 2790
2768static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f, 2791static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
2769 struct pci_fixup *end) 2792 struct pci_fixup *end)