Date: Thu, 24 Apr 2008 08:06:54 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-embedded@freebsd.org Cc: Geoffrey Mainland <mainland@eecs.harvard.edu>, freebsd-usb@freebsd.org Subject: Re: Soekris 4826 USB failure on FreeBSD 7.0 Message-ID: <200804240806.54354.jhb@freebsd.org> In-Reply-To: <200804240916.39607.hselasky@c2i.net> References: <20080421171305.GA19840@eecs.harvard.edu> <20080424033452.GA39119@eecs.harvard.edu> <200804240916.39607.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 24 April 2008 03:16:38 am Hans Petter Selasky wrote: > On Thursday 24 April 2008, Geoffrey Mainland wrote: > > On Wed, Apr 23, 2008 at 07:31:59PM +0200, Hans Petter Selasky wrote: > > > On Tuesday 22 April 2008, Geoffrey Mainland wrote: > > > > Wow, this turns out to be much worse than I thought...I've tracked > > > > down the problem to the commit of the new physical memory allocator > > > > at Sat Jun 16 04:57:05 2007 UTC. Before that, no kern/122380; after > > > > that, kern/122380 applies. Any ideas where to go from here? > > > > > > Hi, > > > > > > I've sometimes seen that the USB HC's do not always support 32 address > > > lines. Not sure if that is the case for you. Then all DMA memory has to > > > be allocated at a lower physical memory address. You can easily check > > > this by changing the parameters used when creating DMA tags in the USB > > > code. > > > > > > --HPS > > > > The new page allocator obviously tickled a bug somewhere in the current > > USB stack, but I'm happy to report that replacing it with the USB stack > > from your subversion repository fixed everything. Thank you! This fix > > has allowed me to move a large wireless testbed forward to FreeBSD 7. > > > > Geoff > > Hi, > > A wild guess of mine why the official USB stack in the 7-branch does not > work: It might be that the loading of KVA into DMA is broken. I've found a > couple of corner cases during my development where you have to generate the > physaddr of the last page yourself in the busdma callback: This would indicate a bug in the bus_dmamap_load() call (wrong length?) and that is going to hose you when you do the bus_dmamap_sync() for systems with bounce pages (not enough data will get copied back and forth?). You need to track down the real bug and fix it rather than adding a hack in your callback routine. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804240806.54354.jhb>