Skip site navigation (1)Skip section navigation (2)
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, Hans Petter Selasky <hselasky@c2i.net>
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>