sparc64/141918: [ehci] ehci_interrupt: unrecoverable error, controller halted (sparc64)

[Marius Strobl]

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 at alchemy.franken.de>
> > > > To: linimon at freebsd.org, bug-followup at freebsd.org, bel at 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 at 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