Date: Wed, 31 Aug 2005 13:21:24 -0600 From: Scott Long <scottl@samsco.org> To: Ian Dowse <iedowse@iedowse.com> Cc: 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: <43160334.5000100@samsco.org> In-Reply-To: <200508302009.aa99975@nowhere.iedowse.com> References: <200508302009.aa99975@nowhere.iedowse.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43160334.5000100>