On Sat, Apr 28, 2001, Martin Diehl <[EMAIL PROTECTED]> wrote:
> 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.
Excellent.
> 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.
There's still the possibility of bugs in my code.
If you can, give me the output of /proc/device/uhci/hc0? That should
help us track this down.
JE
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
