Low umass performance with USB 2.0 ports

[Scott Long]

Hans Petter Selasky wrote:

> On Wednesday 31 August 2005 21:47, Scott Long wrote:
> 
>>Scott Long wrote:
>>
>>>Ian Dowse wrote:
>>>
>>>>In message <20050830125031.GA775 at 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