From: Dan Williams <dan.j.williams@intel.com>
To: "Woodhouse, David" <david.woodhouse@intel.com>
Cc: Chris Li <lkml@chrisli.org>, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: BUG in drivers/dma/ioat/dma_v2.c:314
Date: Thu, 01 Jul 2010 00:26:17 -0700 [thread overview]
Message-ID: <4C2C4319.6090906@intel.com> (raw)
In-Reply-To: <1277968336.4945.3.camel@localhost>
On 7/1/2010 12:12 AM, Woodhouse, David wrote:
> On Thu, 2010-07-01 at 07:51 +0100, Williams, Dan J wrote:
>> This version of the device only exists on the 5400 chipset and always
>> has its own iommu, but since other platforms get the DMAR entry right I
>> think this hammer is too big? Wouldn't this break VT-d operation on
>> non-busted platforms?
>
> That just means we have to get the quirk right. Does 'this version' of
> the device have its own PCI ID? We can always fall back to checking the
> ID of the device at 0000:00:00.0 to check which chipset we're on.
>
PCI_DEVICE_ID_INTEL_IOAT_SNB only exists on this chipset and to date
only "MacPro3,1" platforms have this problem.
>> Alternatively I can just catch this failure earlier in the init process
>> and fail the driver load with a grumble printk about broken bios...
>> instead of the current BUG_ON() that is meant to catch runtime catastrophes.
>
> Please use WARN_TAINT(TAINT_FIRMWARE_WORKAROUND). That way the
> statistics end up in kerneloops.org and we have found that extremely
> useful when LARTing the offending vendors.
>
Good to know, thanks.
--
Dan
next prev parent reply other threads:[~2010-07-01 7:26 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-28 23:50 BUG in drivers/dma/ioat/dma_v2.c:314 Chris Li
2010-06-29 0:45 ` Dan Williams
2010-06-29 7:17 ` Chris Li
2010-06-29 23:20 ` Chris Li
2010-06-29 23:57 ` Dan Williams
2010-06-30 1:07 ` Chris Li
2010-06-30 4:17 ` Dan Williams
2010-06-30 18:26 ` Chris Li
2010-06-30 18:43 ` Chris Li
2010-06-30 18:43 ` David Woodhouse
2010-06-30 19:40 ` Dan Williams
2010-06-30 20:02 ` David Woodhouse
2010-06-30 21:44 ` Dan Williams
2010-06-30 21:59 ` Chris Li
2010-06-30 22:04 ` Dan Williams
2010-07-01 6:21 ` David Woodhouse
2010-07-01 6:51 ` Dan Williams
2010-07-01 7:12 ` David Woodhouse
2010-07-01 7:26 ` Dan Williams [this message]
2010-07-01 8:15 ` David Woodhouse
2010-07-01 17:20 ` Dan Williams
2010-07-01 17:58 ` Chris Li
2010-07-02 19:00 ` Chris Li
2010-07-05 10:16 ` David Woodhouse
2010-07-06 23:40 ` Chris Li
2010-07-07 0:51 ` Dan Williams
2010-07-07 0:51 ` Chris Li
2010-07-07 0:58 ` Dan Williams
2010-07-07 1:03 ` Chris Li
2010-07-07 3:22 ` David Woodhouse
2010-07-07 3:40 ` David Woodhouse
2010-07-07 17:47 ` Dan Williams
2010-07-07 18:07 ` David Woodhouse
2010-07-07 21:56 ` Chris Li
2010-07-09 21:28 ` Dan Williams
2010-07-09 22:00 ` Chris Li
2010-07-10 0:09 ` David Woodhouse
2010-07-15 5:41 ` Dan Williams
2010-07-16 21:29 ` Chris Li
2010-07-16 22:12 ` David Woodhouse
2010-07-16 22:40 ` Chris Li
2010-07-22 1:15 ` Dan Williams
2010-07-22 21:39 ` Chris Li
2010-07-22 22:00 ` Dan Williams
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=4C2C4319.6090906@intel.com \
--to=dan.j.williams@intel.com \
--cc=david.woodhouse@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@chrisli.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.