Re: hpsa driver bug crack kernel down!

["Woodhouse, David" <david.woodhouse@intel.com>]

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

On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote:
> > > > > >> > > > > dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000
> > 
> > That "Present bit in context entry is clear" fault means that we have
> > not set up *any* mappings for this PCI device… on this IOMMU.
> > 
> > > > Yes, specifically (finally done bisecting):
> > > > 
> > > > commit 2e45528930388658603ea24d49cf52867b928d3e
> > > > Author: Jiang Liu <jiang.liu@linux.intel.com>
> > > > Date:   Wed Feb 19 14:07:36 2014 +0800
> > > > 
> > > >     iommu/vt-d: Unify the way to process DMAR device scope array
> > 
> > This commit is about how we decide which IOMMU a given PCI device is
> > attached to.
> > 
> > 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.
> > 
> > However, I'm not 100% convinced of that. The fault address looks
> > suspiciously like a true physical address, not a virtual bus address of
> > the type that we'd normally allocate for a dma_map_* operation. Those
> > would start at 0xfffff000 and work downwards, typically.
> > 
> > Do you have 'iommu=pt' on the kernel command line? 
> 
> No.
> 
> > Can I see the full
> > dmesg as this system boots, and also a copy of the DMAR table?
> 
> Attaching a dmesg from one of the kernels that boots. It doesn't appear
> to have much of the related information... 

It shows us that the address 0x7f61e000 is in an E820-reserved region,
and that there's and RMRR covering that region for an unspecified PCI
device, but that's going to be the hpsa.

So if isn't just a simple case of us assigning this device to the wrong
IOMMU, *perhaps* it's that we lose the RMRR when the driver takes
control of the device. RMRRs are generally expected to be a boot-time
thing, for things like legacy keyboard/mouse emulation via USB. Using
them while the system is *active* is... horrid. We've often not quite
handled that right.

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

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