I'm developing driver for EZUSB-based system. When I use continuous iso-transfer (several urbs connected in the ring), every 986 (sometimes +-3) I get 1 or more urbs, which complete in reverse order.
For example, start_frames in completion routine show up like 20, 21, 23, 22, 24. The next error would be like 6, 7, 9, 8, 10 ... Sometimes even 0, 1, 6, 5, 4, 3, 2, 7, 8 ...
No missing data, just reverse order.
This is with 2.4.20, UHCI (uhci.o) in Dell Inspiron.
Is this a known phenomena, my misunderstanding of something or a bug ...
Bug, also seen in 2.5 ... urbs should report in the order they were queued. (Unless you're not using the ISO_ASAP scheduling policy -- discouraged).
I think it's just a case using the wrong primitive to append the URBs to a list ... see if changing the "list_add" in uhci_add_complete() to be a "list_add_tail" helps. (If so, please submit patches!)
By the way, is there a thumb rule, of how many urbs one should have in a ring ?
Enough to make sure that even in your worst-case IRQ latency, there will always be one in your queue. If you're concerned with the actual delay between sending and receiving, keep that latency down.
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
