On Mon, Apr 12, 2010 at 12:56 PM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxxxxxxxx> 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.. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
