On Sun, Mar 09, 2003, Jouni Ryno <[EMAIL PROTECTED]> wrote:
> 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 ...
Well, it's probably it just an artifact from this code:
list_add(&urbp->complete_list, &uhci->complete_list);
If we complete multiple URBs during one frame, the completion handlers
will be called in reverse order. This may not be what is expected. If
you can, try changing that to list_add_tail and see if it works like you
expect.
However, I'm more worried that this is even happening in the first
place. Why would we have more than 1 (5 in one example!) complete in one
frame. Sounds like something is turning off interrupts for a LONG time.
Do you have APM turned on by chance? The frequency it happens is very
suspicious (a hair less than every second)
> By the way, is there a thumb rule, of how many urbs one should have in a
> ring ?
Atleast 3. It all depends on your latency and reliability requirements.
JE
-------------------------------------------------------
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
