From owner-freebsd-arm@FreeBSD.ORG Fri Jan 30 22:07:20 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D126106564A; Fri, 30 Jan 2009 22:07:20 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id F1EAA8FC14; Fri, 30 Jan 2009 22:07:19 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id DDFB7FF14; Sat, 31 Jan 2009 11:07:18 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-hcH1M0XZTt; Sat, 31 Jan 2009 11:07:15 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sat, 31 Jan 2009 11:07:15 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id E3CC91142D; Sat, 31 Jan 2009 11:07:14 +1300 (NZDT) Date: Fri, 30 Jan 2009 14:07:14 -0800 From: Andrew Thompson To: Sam Leffler Message-ID: <20090130220714.GA10743@citylink.fud.org.nz> References: <20090130072649.GF73709@citylink.fud.org.nz> <49833653.60509@freebsd.org> <20090130173147.GC2160@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090130173147.GC2160@citylink.fud.org.nz> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: arm@freebsd.org Subject: Re: busdma problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2009 22:07:20 -0000 On Fri, Jan 30, 2009 at 09:31:47AM -0800, Andrew Thompson wrote: > On Fri, Jan 30, 2009 at 09:18:11AM -0800, Sam Leffler wrote: > > Andrew Thompson wrote: > >> Hi, > >> > >> > >> 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?? Andrew