Date: Wed, 31 Aug 2005 13:47:15 -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: <43160943.6030400@samsco.org> In-Reply-To: <43160334.5000100@samsco.org> References: <200508302009.aa99975@nowhere.iedowse.com> <43160334.5000100@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------080401070801020504080600
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
--------------080401070801020504080600
Content-Type: text/plain;
name="ehci-flush.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ehci-flush.diff"
Index: ehci.c
===================================================================
RCS file: /usr/ncvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.36
diff -u -r1.36 ehci.c
--- ehci.c 29 May 2005 04:42:27 -0000 1.36
+++ ehci.c 31 Aug 2005 19:44:14 -0000
@@ -578,6 +578,7 @@
return (0);
EOWRITE4(sc, EHCI_USBSTS, intrs); /* Acknowledge */
+ EOREAD4(sc, EHCI_USBCMD); /* Flush posted writes on PCI */
sc->sc_bus.intr_context++;
sc->sc_bus.no_intrs++;
if (eintrs & EHCI_STS_IAA) {
--------------080401070801020504080600--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43160943.6030400>