On Mon, Apr 12, 2010 at 12:56 PM, Sarah Sharp sarah.a.sharp@linux.intel.com wrote:
On Sat, Apr 10, 2010 at 11:02:53AM -0600, Robert Hancock wrote:
On Sat, Apr 10, 2010 at 2:34 AM, Daniel Mack daniel@caiaq.de wrote:
On Fri, Apr 09, 2010 at 05:38:13PM -0600, Robert Hancock wrote:
On Fri, Apr 9, 2010 at 10:50 AM, Sarah Sharp sarah.a.sharp@linux.intel.com wrote:
What makes you think that? I've seen URB buffers with 64-bit DMA addresses. I can tell when the debug polling loop runs and I look at the DMA addresses the xHCI driver is feeding to the hardware:
Dev 1 endpoint ring 0: xhci_hcd 0000:05:00.0: @71a49800 01000680 00080000 00000008 00000841
So the TRB at address 71a49800 is pointing to a buffer at address 0x0008000001000680.
I'm not sure why the address would be that huge, unless it's not actually a physical address, or there's some kind of remapping going on?
If I'm setting a DMA mask wrong somewhere, or doing something else to limit the DMA to 32-bit, then please let me know.
The DMA mask for the controller isn't being set anywhere (in the version that's in Linus' current git anyway). In that case it'll default to 32-bit and any DMA mappings above 4GB will need to be remapped. The controller driver doesn't do the mapping itself but the USB core does, passing in the controller device as the one doing the DMA, so if the controller's DMA mask is set to 32-bit then the buffers passed in will get remapped/bounced accordingly.
So if we're seeing physical addresses in the log above, and the xHCI driver does not explicitly allow the USB core to use addresses above 4GB, why shouldn't the same thing be true as well for EHCI? (Which would then be exactly the case we're seeing)
That is a bit suspicious, yes. With the DMA mask at default I don't expect that should happen. Sarah, what kind of traffic was happening when you saw that (bulk, isochronous, etc)?
Ring 0 is the default control ring, so it must be control transfers. That's the first control transfer on the ring (and it didn't fill), so it must have come from the USB core.
I was running the USB mass storage driver, and the bulk endpoint rings don't have the high 32-bits of the address set. It mostly uses the scatter-gather interface, which calls usb_buffer_map_sg(), so that's not surprising.
Is this machine using an IOMMU or something which would be remapping physical addresses? That address 0x0008000001000680 seems huge, I don't see how it could even be a valid bus address otherwise..