From owner-freebsd-sparc64@FreeBSD.ORG Mon Feb 8 23:45:47 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F01E1065670; Mon, 8 Feb 2010 23:45:47 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0D8568FC12; Mon, 8 Feb 2010 23:45:46 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o18NjhOB010080; Tue, 9 Feb 2010 00:45:43 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o18NjhVS010079; Tue, 9 Feb 2010 00:45:43 +0100 (CET) (envelope-from marius) Date: Tue, 9 Feb 2010 00:45:43 +0100 From: Marius Strobl To: Hans Petter Selasky Message-ID: <20100208234543.GQ77522@alchemy.franken.de> References: <201002080910.o189A3fp080625@freefall.freebsd.org> <201002081520.26468.hselasky@c2i.net> <20100208180549.GB1358@michelle.cdnetworks.com> <201002081924.54241.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002081924.54241.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org, linimon@freebsd.org Subject: Re: sparc64/141918: [ehci] ehci_interrupt: unrecoverable error, controller halted (sparc64) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 23:45:47 -0000 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 > > > > 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