From owner-cvs-src@FreeBSD.ORG Wed Apr 23 21:11:59 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F1CD106564A; Wed, 23 Apr 2008 21:11:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 413AE8FC16; Wed, 23 Apr 2008 21:11:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unknown [208.65.91.234]) by elvis.mu.org (Postfix) with ESMTP id A08671A4D80; Wed, 23 Apr 2008 14:11:58 -0700 (PDT) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m3NLBlTS031930; Wed, 23 Apr 2008 17:11:47 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Sam Leffler Date: Wed, 23 Apr 2008 17:11:43 -0400 User-Agent: KMail/1.9.7 References: <200803201619.m2KGJQr7033985@repoman.freebsd.org> <20080423205943.GG99566@alchemy.franken.de> <480FA41F.20407@freebsd.org> In-Reply-To: <480FA41F.20407@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804231711.43945.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 23 Apr 2008 17:11:47 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/6908/Wed Apr 23 15:48:03 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Marius Strobl Subject: Re: cvs commit: src/sys/dev/usb ehci.c ohci.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2008 21:11:59 -0000 On Wednesday 23 April 2008 05:03:27 pm Sam Leffler wrote: > Marius Strobl wrote: > > On Wed, Apr 23, 2008 at 01:43:55PM -0700, Sam Leffler wrote: > > > >> Marius Strobl wrote: > >> > >>> On Sat, Apr 12, 2008 at 09:33:58PM +0200, Marius Strobl wrote: > >>> > >>> > >>>> On Thu, Mar 20, 2008 at 04:19:26PM +0000, Sam Leffler wrote: > >>>> > >>>> > >>>>> sam 2008-03-20 16:19:25 UTC > >>>>> > >>>>> FreeBSD src repository > >>>>> > >>>>> Modified files: > >>>>> sys/dev/usb ehci.c ohci.c > >>>>> Log: > >>>>> Workaround design botch in usb: blindly mixing bus_dma with PIO does > >>>>> not > >>>>> work on architectures with a write-back cache as the PIO writes end up > >>>>> in the cache which the sync(BUS_DMASYNC_POSTREAD) in > >>>>> usb_transfer_complete > >>>>> then discards; compensate in the xfer methods that do PIO by pushing > >>>>> the > >>>>> writes out of the cache before usb_transfer_complete is called. > >>>>> > >>>>> This fixes USB on xscale and likely other places. > >>>>> > >>>>> Sponsored by: hobnob > >>>>> Reviewed by: cognet, imp > >>>>> MFC after: 1 month > >>>>> > >>>>> Revision Changes Path > >>>>> 1.62 +16 -0 src/sys/dev/usb/ehci.c > >>>>> 1.171 +16 -0 src/sys/dev/usb/ohci.c > >>>>> > >>>>> > >>>> This causes a crash during boot on sparc64. Looks like map is still > >>>> NULL at that point. > >>>> > >>>> > >>>> > >>> Are you ok with the change below or would that also prevent > >>> your kludge from taking effect? > >>> > >>> Marius > >>> > >>> Index: ehci.c > >>> =================================================================== > >>> RCS file: /usr/data/bsd/cvs/fbsd/src/sys/dev/usb/ehci.c,v > >>> retrieving revision 1.62 > >>> diff -u -r1.62 ehci.c > >>> --- ehci.c 20 Mar 2008 16:19:25 -0000 1.62 > >>> +++ ehci.c 23 Apr 2008 20:23:58 -0000 > >>> @@ -664,6 +664,8 @@ > >>> usbd_pipe_handle pipe = xfer->pipe; > >>> bus_dma_tag_t tag = pipe->device->bus->buffer_dmatag; > >>> struct usb_dma_mapping *dmap = &xfer->dmamap; > >>> + if (dmap->map == NULL) > >>> + return; > >>> bus_dmamap_sync(tag, dmap->map, BUS_DMASYNC_PREWRITE); > >>> } > >>> > >>> Index: ohci.c > >>> =================================================================== > >>> RCS file: /usr/data/bsd/cvs/fbsd/src/sys/dev/usb/ohci.c,v > >>> retrieving revision 1.171 > >>> diff -u -r1.171 ohci.c > >>> --- ohci.c 20 Mar 2008 16:19:25 -0000 1.171 > >>> +++ ohci.c 21 Apr 2008 19:13:54 -0000 > >>> @@ -1571,6 +1571,8 @@ > >>> usbd_pipe_handle pipe = xfer->pipe; > >>> bus_dma_tag_t tag = pipe->device->bus->buffer_dmatag; > >>> struct usb_dma_mapping *dmap = &xfer->dmamap; > >>> + if (dmap->map == NULL) > >>> + return; > >>> bus_dmamap_sync(tag, dmap->map, BUS_DMASYNC_PREWRITE); > >>> } > >>> > >>> > >>> > >>> > >>> > >> You have not identified why you don't have a dma map. I don't have a > >> way to diagnose your problem and so far as I know no other platform had > >> an issue w/ the change. I suggest you figure out why your map is not > >> setup instead of adding a hack. > >> > >> > > > > It's because the usb(4) code doesn't create DMA maps for > > zero-length transfers, see usbd_transfer(). In the case of > > the backtrace I posted not for usbd_set_address(), which > > does USETW(req.wLength, 0) so later on size is 0 in > > usbd_transfer() hence no DMA map. I don't know why your > > hack doesn't also crash other platforms. > > > Thanks for explaining, I will look. Please hold off for a bit. Also, other archs may not be crashing because some of them use a NULL map for bus_dmamem_alloc() as a sentinel of sorts so that sync operations are nops (since bus_dmamem_alloc() won't alloc memory that needs to be bounced, etc.). -- John Baldwin