From owner-freebsd-usb@FreeBSD.ORG Tue Dec 18 12:10:16 2012 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AAEEDE6; Tue, 18 Dec 2012 12:10:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id D1C848FC14; Tue, 18 Dec 2012 12:10:15 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 358305837; Tue, 18 Dec 2012 13:05:06 +0100 From: Hans Petter Selasky To: Andrew Turner Subject: Re: EHCI on armv6 with Write-Back caches Date: Tue, 18 Dec 2012 13:06:44 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20121218204931.5322922d@fubar.geek.nz> <201212180922.22217.hselasky@c2i.net> <20121219000213.269b1371@fubar.geek.nz> In-Reply-To: <20121219000213.269b1371@fubar.geek.nz> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212181306.44926.hselasky@c2i.net> Cc: Oleksandr Tymoshenko , freebsd-usb@freebsd.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:10:16 -0000 On Tuesday 18 December 2012 12:02:13 Andrew Turner wrote: > On Tue, 18 Dec 2012 09:22:22 +0100 > > Hans Petter Selasky wrote: > > On Tuesday 18 December 2012 08:49:31 Andrew Turner wrote: > > > Hello, > > > > > > Oleksandr and myself have been looking into why when we enable the > > > write-back cache on the PandaBoard there are kernel panics with > > > USB. We have tracked it down to an issue appending the ehci_qh_t to > > > the list at the end of ehci_setup_standard_chain(). > > > > > > I have a patch at [1] that allows me to run sha256 on a 40MB file > > > over NSF using the built in smsc USB ethernet chip. The problem is > > > I have had to place a call to DELAY before EHCI_APPEND_QH. This is > > > obviously not the correct solution. > > > > > > Is anyone able to help me narrow down what is missing? It appears > > > to be a missing cache invalidate or flush somewhere but I haven't > > > been able to track down what cache function the DELAY is working > > > around. > > > > > > Andrew > > > > > > [1] http://fubar.geek.nz/files/freebsd/ehci_4.diff > > > > Hi, > > > > Can you dump the DMA tag belonging to the QH via and check wether it > > is mapped coherent or not. Thes QH- and TD- structures should not be > > cache mapped. Else cache has not been disabled on those pages. > > > > qh->page_cache->tag > Hi Andrew, > The BUS_DMA_COHERENT flag does nothing on armv6 as we need the cache > enabled for atomic operations to work correctly and we would have to > disable the cache on the entire page. This is acceptable behaviour from > the description of the flag in the busdma man page. Yes, but when I allocate memory from the USB stack, then I want that memory to not be cached. It is simply not that useful to have that memory cached. I didn't check the latest state of busdma, but if I'm not mistaken, if the BUS_DMA_COHERENT flag is set on the DMA tag, the flush/invalidate will simply return and do nothing. Maybe that is the problem ... > > Is there a reason the QH and TD structures shouldn't be cache mapped? Because they are frequently used for setting up data operations, and the flush/invalidate operate on the whole page where multiple tags can be present, notably for the same USB transfer, under the same mutex. So it slows down everything. --HPS