[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1397206629.19944.54.camel@shinybook.infradead.org>
Date: Fri, 11 Apr 2014 09:57:09 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Shuah Khan <shuahkhan@...il.com>
Cc: scameron@...rdog.cce.hp.com, Davidlohr Bueso <davidlohr@...com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Baoquan He <bhe@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-scsi <linux-scsi@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
Joerg Roedel <joro@...tes.org>,
"open list:INTEL IOMMU (VT-d)" <iommu@...ts.linux-foundation.org>,
Jiang Liu <jiang.liu@...ux.intel.com>
Subject: Re: hpsa driver bug crack kernel down!
On Thu, 2014-04-10 at 17:17 -0600, Shuah Khan wrote:
> This smells very much like the problem that was solved couple of years
> ago for SI domain. It is likely that path is broken with the DMAR
> device scope array change. Please take a look to see if the following
> no longer occurs. Looks like BIOS could be expecting this RMRR to be
> still mapped.
>
> /*
> * We want to prevent any device associated with an RMRR from
> * getting placed into the SI Domain. This is done because
> * problems exist when devices are moved in and out of domains
> * and their respective RMRR info is lost. We exempt USB devices
> * from this process due to their usage of RMRRs that are known
> * to not be needed after BIOS hand-off to OS.
> */
> if (device_has_rmrr(dev) &&
> (pdev->class >> 8) != PCI_CLASS_SERIAL_USB)
> return 0;
Yeah, I'd be inclined to agree.... although I've tested with graphics
*since* these patches. That's another case where we need to preserve the
RMRR mapping after the driver takes over — and it *was* working.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@...el.com Intel Corporation
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5745 bytes)
Powered by blists - more mailing lists