lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 22 May 2010 12:09:05 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Matthew Wilcox <matthew@....cx>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	linux-pci@...r.kernel.org, linux1394-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org,
	Dominik Brodowski <linux@...inikbrodowski.net>
Subject: Re: DMAR:[fault reason 02] Present bit in context entry is clear
 (firewire-ohci)

On Sat, 22 May 2010 19:40:43 +0100
David Woodhouse <dwmw2@...radead.org> wrote:

> On Sat, 2010-05-22 at 06:12 -0600, Matthew Wilcox wrote:
> > On Sat, May 22, 2010 at 12:26:15PM +0200, Stefan Richter wrote:
> > > Hi,
> > > 
> > > I came across a report of the subject message.  What does it mean; what
> > > type of bug should be look for?
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=587178
> > > >>>
> > > firewire_ohci 0000:04:00.4: PCI INT C -> GSI 16 (level, low) -> IRQ 16
> > > firewire_ohci 0000:04:00.4: setting latency timer to 64
> > > firewire_ohci: Added fw-ohci device 0000:04:00.4, OHCI version 1.0
> > > DRHD: handling fault status reg 2
> > > DMAR:[DMA Read] Request device [04:00.0] fault addr fffff000
> > > DMAR:[fault reason 02] Present bit in context entry is clear
> > > DMAR:[DMA Read] Request device [04:00.0] fault addr fffff000
> > > DMAR:[fault reason 02] Present bit in context entry is clear
> > > DMAR:[DMA Read] Request device [04:00.0] fault addr fffff000
> > > DMAR:[fault reason 02] Present bit in context entry is clear
> > > <<<
> > > 
> > > The log sounds as if this happens during from-device DMA of 04:00.4 into
> > > a consistent buffer, yet the fault is logged for device 04:00.0.  The
> > > log is from a Dell M4500.  The devices are, according to a web search,
> > > 04:00.0 CardBus bridge [0607]: Ricoh Co Ltd Device [1180:e476] (rev 02)
> > > 04:00.4 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd Device [1180:e832]
> > > (rev 03) (prog-if 10)
> > 
> > I would guess that the DMAR can't distinguish between the different
> > devices behind the Cardbus bridge.  Adding Dave Woodhouse.
> 
> Yeah, the DMAR looks at the source-id in the PCIe transactions, and it
> sounds like those are all 04:00.0. But we've probably set up the DMAR to
> allow the transactions from 04:00.4, and then it naturally faults when a
> "different" device actually ends up doing the transaction.
> 
> If you make the pci_find_upstream_pcie_bridge() function do the
> appropriate thing for this device, does it then work as expected?
> 
> Whether that's a _sane_ thing to do or not is possibly more of a Jesse
> question...

Well, if cardbus bridges tend to behave this way in general it would
make sense to simply use the cardbus bride id everywhere, rather than
the specific functions of the device.  Cc'ing Dominik.

Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ