linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Woodhouse, David" <david.woodhouse@intel.com>
To: "Elliott@hp.com" <Elliott@hp.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bhe@redhat.com" <bhe@redhat.com>,
	"jiang.liu@linux.intel.com" <jiang.liu@linux.intel.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"James.Bottomley@hansenpartnership.com"
	<James.Bottomley@hansenpartnership.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"scameron@beardog.cce.hp.com" <scameron@beardog.cce.hp.com>,
	"davidlohr@hp.com" <davidlohr@hp.com>
Subject: Re: hpsa driver bug crack kernel down!
Date: Thu, 10 Apr 2014 15:34:26 +0000	[thread overview]
Message-ID: <1397144058.1308.22.camel@i7.infradead.org> (raw)
In-Reply-To: <CAErSpo6EORf02WS1UqP8EMWfHij7W2J5B3ZOoBT90txV85uZZw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

On Thu, 2014-04-10 at 09:14 -0600, Bjorn Helgaas wrote:
> > Thus, my first guess would be that we are quite happily setting up the
> > requested DMA maps on the *wrong* IOMMU, and then taking faults when the
> > device actually tries to do DMA.
> >
> I like the "wrong IOMMU (or no IOMMU at all)" theory.  If we didn't
> connect the device with an IOMMU at all, that would explain the device
> DMAing directly to a physical address, wouldn't it?

An unlikely failure mode. We're much more likely to see *wrong* IOMMU
than no IOMMU. And thus we'd still see the distinctive virtual addresses
just below 4GiB.

However, Rob's answer may solve that puzzle. If this is one of those
abominations where the device continues to do DMA to system memory even
after the OS is up and running and *thinks* it has control of the
hardware, then the offending address will be listed in an RMRR entry
(which tells the OS to set up a 1:1 mapping for access to certain memory
ranges for a given device). And will be inside an E820 reserved region.

A little odd that such an error would trigger only when we're actually
trying to initialise the device from the Linux driver, not as soon as we
enable the IOMMU. But all things are possible.

But the DMAR table and dmesg that I asked for would give us a bit more
information and hopefully let us stop speculating...

> > We should also rate-limit DMA faults, which would avoid the lockup
> > failure mode. Bjorn, what should an IOMMU driver *do* when it detects
> > that a device is creating an endless stream of DMA faults and isn't
> > aborting the transaction?
> 
> You mentioned that POWER with EEH does something intelligent in this
> case, but I'm not familiar with that code.  We have AER support, which
> can result in resetting a device, but I think DMA faults are reported
> differently, and I don't think there's any nice existing way for PCI
> to deal with them.  Maybe there should be, though.

Quite frankly, I don't care how *you* deal with them, or even if you
can. All I want to know is how I tell you about the problem, because *I*
sure as hell don't want to be trying to deal with it in the IOMMU code.
That's a generic PCI layer thing. :)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3437 bytes --]

  reply	other threads:[~2014-04-10 15:37 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140409023935.GE11839@dhcp-16-105.nay.redhat.com>
     [not found] ` <1397083799.2608.20.camel@buesod1.americas.hpqcorp.net>
     [not found]   ` <1397084904.9519.62.camel@dabdike>
     [not found]     ` <1397085044.9519.63.camel@dabdike>
     [not found]       ` <1397086817.2608.25.camel@buesod1.americas.hpqcorp.net>
2014-04-09 23:50         ` hpsa driver bug crack kernel down! James Bottomley
2014-04-10  0:19           ` Davidlohr Bueso
2014-04-10  4:03             ` Bjorn Helgaas
2014-04-10  6:32               ` Davidlohr Bueso
2014-04-10  7:15                 ` Joerg Roedel
2014-04-10  8:46                   ` Woodhouse, David
2014-04-10 15:14                     ` Bjorn Helgaas
2014-04-10 15:34                       ` Woodhouse, David [this message]
2014-04-10 15:36                       ` Linda Knippers
2014-04-10 16:19                     ` Davidlohr Bueso
2014-04-10 16:30                       ` Woodhouse, David
2014-04-11  9:18                       ` Woodhouse, David
2014-04-14 15:45                         ` Davidlohr Bueso
2014-04-14 16:19                           ` Jiang Liu
2014-04-14 16:44                             ` Davidlohr Bueso
2014-04-14 16:47                               ` Davidlohr Bueso
2014-04-14 17:03                                 ` Woodhouse, David
2014-04-16 13:37                                   ` joro
2014-04-16 13:58                                     ` Woodhouse, David
2014-04-16 14:13                                       ` joro
2014-04-14  7:01                       ` Jiang Liu
2014-04-14  8:57                       ` Jiang Liu
2014-04-14 18:08                         ` Davidlohr Bueso
2014-04-10 20:45                 ` scameron
2014-04-10 23:17                   ` Shuah Khan
2014-04-11  8:57                     ` David Woodhouse
2014-04-10  8:34               ` Jiang Liu
2014-04-10 15:54                 ` Davidlohr Bueso
2014-04-10 16:02                 ` Davidlohr Bueso
2014-04-11  1:34                 ` Baoquan He
2014-04-11  3:14                 ` Baoquan He

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=1397144058.1308.22.camel@i7.infradead.org \
    --to=david.woodhouse@intel.com \
    --cc=Elliott@hp.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=bhe@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=davidlohr@hp.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jiang.liu@linux.intel.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=scameron@beardog.cce.hp.com \
    /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;
as well as URLs for NNTP newsgroup(s).