Messages in this thread Patch in this message | | | Subject | Re: Misc fixes for 2.6.27 | From | David Woodhouse <> | Date | Tue, 02 Sep 2008 09:23:10 +0100 |
| |
On Tue, 2008-09-02 at 08:19 +0200, Andi Kleen wrote: > On Mon, Sep 01, 2008 at 04:16:39PM -0700, Arjan van de Ven wrote: > > On Tue, 02 Sep 2008 01:01:19 +0200 > > Andi Kleen <andi@firstfloor.org> wrote: > > > > > Arjan van de Ven <arjan@infradead.org> writes: > > > > > > > On Tue, 02 Sep 2008 00:32:16 +0200 > > > > Andi Kleen <andi@firstfloor.org> wrote: > > > > > > > >> David Woodhouse <dwmw2@infradead.org> writes: > > > >> > + > > > >> > +static struct dmi_system_id __initdata intel_iommu_dmi_table[] > > > >> > = { > > > >> > + { /* Some DG33BU BIOS revisions advertised > > > >> > non-existent VT-d */ > > > >> > > > >> Are you sure it's non existent? A G33 chipset should have it in > > > >> hardware I thought. > > > > > > > > nope they don't/ > > > > later ones and some other models do though, but not the G33 > > > > > > I see. But presumably that chipset will be in other motherboards > > > too and that BIOS bug might be also wider spread. So it would be > > > still better to key off an PCI-ID or similar.
It's certainly possible that the same BIOS bug could show up elsewhere. I was expecting that we could add new motherboards to the DMI table if that happens.
> > it would be nice, no doubt, unfortunately this code runs (and needs to > > run) before the PCI subsystem is initialized... > > early quirks handles these cases. Check out early-quirks.c
That might work, I suppose -- although the iommu probe happens early, it looks like the early-quirks are handled even earlier. Unfortunately the last attempt at flashing a BIOS on my DG33BU has turned it into a brick and even the recovery procedure doesn't work, so I can't test any more -- I'm more inclined to stick with what I'd tested, but if you feel strongly and someone can test this version, then perhaps we could go with that instead...
I made it check for this: 00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] (rev 02)
Are we sure that device never going to appear on a board which really _does_ have an IOMMU? And we should probably get it into pci_ids.h too.
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c index 4353cf5..f51f61b 100644 --- a/arch/x86/kernel/early-quirks.c +++ b/arch/x86/kernel/early-quirks.c @@ -95,6 +95,20 @@ static void __init nvidia_bugs(int num, int slot, int func) } +#ifdef CONFIG_DMAR +static void __init intel_g33_dmar(int num, int slot, int func) +{ + struct acpi_table_header *dmar_tbl; + acpi_status = status; + + status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl); + if (ACPI_SUCCESS(status)) { + printk(KERN_INFO "BIOS BUG: DMAR advertised on Intel G31/G33 chipset -- ignoring\n"); + dmar_disabled = 1; + } +} +#endif + #define QFLAG_APPLY_ONCE 0x1 #define QFLAG_APPLIED 0x2 #define QFLAG_DONE (QFLAG_APPLY_ONCE|QFLAG_APPLIED) @@ -114,6 +128,10 @@ static struct chipset early_qrk[] __initdata = { PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs }, { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB, PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, fix_hypertransport_config }, +#ifdef CONFIG_DMAR + { PCI_VENDOR_ID_INTEL, 0x29c0, + PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, intel_g33_dmar }, +#endif {} };
-- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation
| |