Date: Tue, 3 Feb 2009 15:30:28 -0800 From: Andrew Thompson <thompsa@FreeBSD.org> To: Sam Leffler <sam@freebsd.org> Cc: arm@freebsd.org Subject: Re: busdma problem Message-ID: <20090203233028.GA68871@citylink.fud.org.nz> In-Reply-To: <20090130220714.GA10743@citylink.fud.org.nz> References: <20090130072649.GF73709@citylink.fud.org.nz> <49833653.60509@freebsd.org> <20090130173147.GC2160@citylink.fud.org.nz> <20090130220714.GA10743@citylink.fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 30, 2009 at 02:07:14PM -0800, Andrew Thompson wrote: > On Fri, Jan 30, 2009 at 09:31:47AM -0800, Andrew Thompson wrote: > > >> I am having an issue with busdma when bounce buffers are used. I have > > >> patched _bus_dmamap_sync_bp() to print out the details when a bounce > > >> happens and also print the driver buffer before and after. > > >> > > >> During normal dma everything is fine, > > >> > > >> Before: 0xc7c1ab40 data=c1:4b:a4:80:c0:5d:ed:78:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: > > >> [...do dma...] > > >> After: 0xc7c1ab40 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00: > > >> > > >> The buffer 2c:03:4e:00:... is the correct response from the hardware. > > >> When a bounce buffer is used I see the correct data come in and be > > >> bcopy'd to my memory region but it is not visible when read later. > > >> > > >> Before: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: > > >> dma bounced 0x1271000 -> 0xc7c29b40 len=193 data=2c:03:4e:00:6f:00:76:00:61:00:74:00:65:00:6c:00:20:00:57:00:69:00:72:00: > > >> After: 0xc7c29b40 data=c1:50:19:00:c0:5d:ed:f8:00:00:08:0d:c1:1f:46:78:00:00:20:02:00:00:20:02: > > >> > > >> > > >> This is on an xscale ixp425 with 128m memory, the PCI dma tag is limited > > >> to 64m. > > >> > > > What device is involved? Is this on HEAD? > > > > This is usb/ehci. The specific function I am looking at is > > usbd_get_string() in usbdi.c, it does a usb request to fill > > usb_string_descriptor_t that is a stack variable. > > As suggested by Sam, this works properly when the buffer is malloc'd > instead of taken from the stack. So is this now a bug or a feature?? As a test I removed the checking of KENTER_CACHE in arm/arm/pmap.c:pmap_kenter_internal() so all memory is uncached and now dma bounces to a stack variable work. busdma remaps the address nocache into vaddr_nocache pointer and uses that for the bcopy, obviously arm_remap_nocache() is not working correctly. Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090203233028.GA68871>