From: Ingo Molnar <mingo@elte.hu>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org, andi@firstfloor.org,
arjan@infradead.org, torvalds@linux-foundation.org,
sfr@canb.auug.org.au, Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH] Blacklist DMAR on Intel G31/G33 chipsets
Date: Sat, 6 Sep 2008 17:49:35 +0200 [thread overview]
Message-ID: <20080906154935.GD1774@elte.hu> (raw)
In-Reply-To: <1220640430.2985.389.camel@pmac.infradead.org>
* David Woodhouse <dwmw2@infradead.org> wrote:
> On Fri, 2008-09-05 at 20:34 +0200, Ingo Molnar wrote:
> > * David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > > Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
> > > when they don't. Avoid the resulting crashes when it doesn't work as
> > > expected.
> > >
> > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> > > ---
> > >
> > > This time, I build-tested it with CONFIG_DMAR actually enabled. Sorry.
> > > I'd still be grateful if someone could test it on a DG33BU with the
> > > old BIOS though, since I've killed mine. I tested the DMI version, but
> > > not this one.
> >
> > ok - fixing this makes sense. I have two worries about this patch.
> >
> > Firstly, the quirk is keyed off an ACPI capability which is quite bad if
> > someone boots with ACPI off. (which is still quite possible) The DMAR is
> > PCI enumerated so there's nothing inherently ACPI about this. A DMI
> > quirk (which will work even if ACPI is disabled) looks more robust.
>
> No, the intel-iommu code is isn't PCI-enumerated -- it all depends on
> that ACPI table, unfortunately. [...]
ah, you are right ... and i thought i could trust grep -i acpi
drivers/pci/intel-iommu.c coming up empty ;-)
Jesse's call obviously, but the DMI thing local to intel-iommu.c still
looks better to me in all regards. I'm no fan of DMI in general - it
just doesnt scale - but here a crappy BIOS gets punished with a DMI
quirk and that's OK.
Ingo
next prev parent reply other threads:[~2008-09-06 15:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-01 20:14 Misc fixes for 2.6.27 David Woodhouse
2008-09-01 22:32 ` Andi Kleen
2008-09-01 22:35 ` Arjan van de Ven
2008-09-01 23:01 ` Andi Kleen
2008-09-01 23:16 ` Arjan van de Ven
2008-09-02 6:19 ` Andi Kleen
2008-09-02 8:23 ` David Woodhouse
2008-09-03 10:53 ` Blacklist DMAR on Intel G31/G33 chipsets David Woodhouse
2008-09-03 12:09 ` Andi Kleen
2008-09-03 12:22 ` David Woodhouse
2008-09-04 8:54 ` [PATCH] " David Woodhouse
2008-09-05 18:34 ` Ingo Molnar
2008-09-05 18:47 ` David Woodhouse
2008-09-06 15:49 ` Ingo Molnar [this message]
2008-09-07 8:20 ` David Woodhouse
2008-09-07 15:35 ` [2.6.27 PATCH] " David Woodhouse
2008-09-09 18:39 ` Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080906154935.GD1774@elte.hu \
--to=mingo@elte.hu \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=dwmw2@infradead.org \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox