Date: Tue, 9 Feb 2010 00:45:43 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-sparc64@freebsd.org, linimon@freebsd.org Subject: Re: sparc64/141918: [ehci] ehci_interrupt: unrecoverable error, controller halted (sparc64) Message-ID: <20100208234543.GQ77522@alchemy.franken.de> In-Reply-To: <201002081924.54241.hselasky@c2i.net> References: <201002080910.o189A3fp080625@freefall.freebsd.org> <201002081520.26468.hselasky@c2i.net> <20100208180549.GB1358@michelle.cdnetworks.com> <201002081924.54241.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 08, 2010 at 07:24:54PM +0100, Hans Petter Selasky wrote: > On Monday 08 February 2010 19:05:49 Pyun YongHyeon wrote: > > On Mon, Feb 08, 2010 at 03:20:26PM +0100, Hans Petter Selasky wrote: > > > On Monday 08 February 2010 10:10:03 Marius Strobl wrote: > > > > The following reply was made to PR sparc64/141918; it has been noted by > > > > GNATS. > > > > > > > > From: Marius Strobl <marius@alchemy.franken.de> > > > > To: linimon@freebsd.org, bug-followup@freebsd.org, bel@orel.ru > > > > Cc: > > > > Subject: Re: sparc64/141918: [ehci] ehci_interrupt: unrecoverable > > > > error, controller halted (sparc64) Date: Mon, 8 Feb 2010 10:07:42 +0100 > > > > > > > > On Mon, Feb 08, 2010 at 07:05:29AM +0000, linimon@freebsd.org wrote: > > > > > hps claims that this may be sparc64-specific. > > > > > > > > As outlined here it's unlikely that this is a problem of the sparc64 > > > > bus_dmamap_sync(9): > > > > > > Hi, > > > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-sparc64/2009-December/006866 > > > >.ht ml There are however known problems with usb(4) in this regard, see > > > > for > > > > > > The issue mentioned above was patched in 9-current some months back. Have > > > you tried 9-current? > > > > > > > http://svn.freebsd.org/viewvc/base?view=revision&revision=203080 > > > > > > On point about busdma is that you should be able to pass any kernel > > > virtual address to be loaded into DMA. If the kernel virtual address is > > > not correctly aligned, a bounce page must be used, so that surrounding > > > memory is not disturbed. And that is not an USB problem. > > > > Would you elaborate on this? I don't think sparc64 needs bounce > > buffer as it uses DVMA. I have no idea how bounce buffer can > > address the alignment mismatches unless bounce buffer is created on > > certain alignment boundary. > > If you put the data in a bounce buffer, you can clear data before and after > the actual data without caring too much about it. > Are you talking about the busdma implementation or the DMA engine/ driver clearing data before/after the "actual" data? The latter two simply can't make such assumptions. If the former amd64/i386 style bounce buffers won't happen on sparc64 as this would require bypassing the IOMMU which is affected by hardware errata and thus is no viable option. Is there way to avoid the alignment mismatches in usb(4)? Looking at usb_pc_alloc_mem() it seems to play with the alignment and size for no real good reason. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100208234543.GQ77522>