On Thu, 26 Apr 2001, Johannes Erdfelt wrote:
> This includes the bulk queuing fixes, the pci consistent support, the
> completion list to fix the deadlocks and various other bug fixes.
>
> If you've had any problems with uhci.c in past, I'd really appreciate it
> if you can test that version and tell me if you still have any problems,
> if you have any new problems, or your problems are gone now.
Although I haven't used it before, you made me curious about the queued
bulk opportunity. So I changed my little test driver for the EZ-USB FX
development board to give them a try (using vanilla 2.4.4-pre8).
I used 2 bulk-in urb's both asking for len=2112 (=2K+1packet) bytes. Both
are submitted queued, but unlinked - i.e. with urb->next==NULL. Whenever
one of them has been copied to userland it is resubmitted and reading
continues on the other one (after test/sleep for completion). Both urb's
were addressed to the same endpoint. Submitting always returned no error.
Well, it basically works: the transfers are properly scheduled one after
the other without the unusable "turn time" gap between consecutive
resubmit of a single urb. I.e. whenever a transfer ends somewhere in the
middle of a frame the next one immediately takes over - apparently always
16 packet (64 byte) per frame transfered. This boosts the sustained
throughput approx. from 500kB/sec to 1MB/sec - i.e. comparable to what I
get when using very large (64/128kB) single transfers one after the other.
Looks pretty good - but I wouldn't have written the above if there weren't
a problem: If I do large continuous transfers - for example using
dd if=/dev/usbdev of=/dev/null bs=2112 count=1M (or other big value)
the transfer gets halted somewhere. The process sleeping in read() never
awakes. For some reason the completion handler is not called to awake it.
I've changed to sleep with timeout so I escape after 5 seconds. Testing
the status gives EINPROGRESS. So I'm pretty sure it's not my driver having
missed the completion due to some race for example. Putting some printk's
into the uhci_interrupt() path shows there are no interrupts occuring
anymore. Looking at the wire the scope shows nothing but idle bus with
normal SOF-packets - nothing else. Furthermore no error or warning appears
in the log (debug=2). Seems to me the controller had succesfully finished
the transfer and the HCD missed this somehow.
If the box is idle this happens sometimes within the 1st second, sometimes
after up to 10 or 15 seconds. Putting significant memory and i/o stress on
the box (swapping f.e.) increases the probability. Testbox is UP.
Well, the switch to queued bulk transfer was a quick hack, so I would not
claim the driver being 100% bugfree. However, if I do exactly the same
thing using usb-uhci instead of uhci it works fine - no such problem after
an hour continously dd'ing!
Unfortunately that's all I can tell at the moment.
Martin
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
