Date: Wed, 31 Aug 2005 15:21:36 -0600 From: Scott Long <scottl@samsco.org> To: hselasky@c2i.net Cc: Ian Dowse <iedowse@iedowse.com>, freebsd-hackers@freebsd.org, hackers@freebsd.org, Eugene Grosbein <eugen@kuzbass.ru>, freebsd-usb@freebsd.org, "Eygene A. Ryabinkin" <freebsd@rea.mbslab.kiae.ru> Subject: Re: Low umass performance with USB 2.0 ports Message-ID: <43161F60.8010408@samsco.org> In-Reply-To: <200508312239.04897.hselasky@c2i.net> References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org> <43160943.6030400@samsco.org> <200508312239.04897.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43161F60.8010408>