From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 31 21:21:41 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EBD116A41F; Wed, 31 Aug 2005 21:21:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBBAB43D49; Wed, 31 Aug 2005 21:21:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j7VLZDes009172; Wed, 31 Aug 2005 15:35:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <43161F60.8010408@samsco.org> Date: Wed, 31 Aug 2005 15:21:36 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hselasky@c2i.net References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <200508312239.04897.hselasky@c2i.net> In-Reply-To: <200508312239.04897.hselasky@c2i.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=3.8 tests=ALL_TRUSTED,URIBL_SBL autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Ian Dowse , freebsd-hackers@freebsd.org, hackers@freebsd.org, Eugene Grosbein , freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" Subject: Re: Low umass performance with USB 2.0 ports X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 21:21:41 -0000 Hans Petter Selasky wrote: > On Wednesday 31 August 2005 21:47, Scott Long wrote: > >>Scott Long wrote: >> >>>Ian Dowse wrote: >>> >>>>In message <20050830125031.GA775@rea.mbslab.kiae.ru>, "Eygene A. >>>>Ryabinkin" wri >>>> >>>>tes: >>>> >>>>>>What is filesystem has your USB drive? >>>>> >>>>>The one I was extensively testing has FAT, but I've checked the UFS2 -- >>>>>just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at >>>>>all. >>>>> >>>>> >>>>>>FreeBSD 4.x had very low performance with FAT filesystem, >>>>>>writing process spent lots of time in the wdrain state too. >>>>> >>>>>Yes, it has. But here the same flash drive gives different results for >>>>>ehci and uhci devices, and the total speed of echi is lower due to >>>>>wdrains: >>>>>300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the >>>>>Windows >>>>>partition with FAT to my home HDD -- it has no wdrains. At least, >>>>>I've not >>>>>noticed them. For flash I can. >>>> >>>>The patch in from the email below may help with the wdrain state - >>>>can you see if it makes any difference? >>> >>>Is the problem that the interrupt gets fired but not all of the status >>>information has made it's way back to host memory when the driver gets >>>there? Would it make a difference to instead read back the EHCI_USBSTS >>>register after writing to it in ehci_intr1? That way all transactions >>>down to the controller would be guaranteed to be flushed before you >>>continue on. I wonder if this is a remnant of the famous problems with >>>VIA chipsets doing bad things under medium-to-high PCI contention. I >>>don't see any obvious workarounds for this in the Linux EHCI code, so >>>I wonder if it's a case of them not encountering it, or doing something >>>different that avoids the problem. >>> >>>Scott >> >>Actually, I just peeked inside the Linux EHCI code and it does a dummy >>read immediately after writing to the status register: >> >> /* clear (just) interrupts */ >> writel (status, &ehci->regs->status); >> readl (&ehci->regs->command); /* unblock posted write */ >> >>I wonder if that's the whole trick here. Would someone be willing to >>try the attached patch instead of the one that Ian posted? >> >>Scott > > > This is not documented in the EHCI chip specification. Flushing posted writes is something that all programmers of PCI devices should understand, so it usually isn't documented in device manuals. > There exists the > doorbell to ensure that the EHCI controller is finished with data structures. > Also I have noticed that the existing EHCI driver does not always dequeue > structures from the controller before accessing them. > Can you point to an example here? > If Scott's patch doesn't work, could you have tried to install the following > (compiles on FreeBSD 5/6/7): > Yeah, looks like my guess was wrong. Scott