Re: Low umass performance with USB 2.0 ports
From: Scott Long (scottl_at_samsco.org)
Date: 08/31/05
- Previous message: Rojer: "Re: Low umass performance with USB 2.0 ports"
- In reply to: Hans Petter Selasky: "Re: Low umass performance with USB 2.0 ports"
- Next in thread: Scott Long: "Re: Low umass performance with USB 2.0 ports"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 31 Aug 2005 15:21:36 -0600 To: hselasky@c2i.net
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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Rojer: "Re: Low umass performance with USB 2.0 ports"
- In reply to: Hans Petter Selasky: "Re: Low umass performance with USB 2.0 ports"
- Next in thread: Scott Long: "Re: Low umass performance with USB 2.0 ports"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
