The delay I found was that the periodic frame list was completely full and no more slots were available. The callback code was not freeing urbs fast enough.
So I was right -- the problem _was_ in your driver. A simple policy of keeping only 200 msec of buffers queued wouldn't have had such problems, in any hardware config.
Why are you queuing so many URBs? If I were to suggest a policy for how deep a transfer queue _should_ be, I'd have started with something smaller, like 16 or 32 msec ... that's enough to cover a reasonable amount of IRQ blockage, especially when you can rely on realtime deadlines with the video processing.
Anyway, I completed the callback-by-tasklet mod today and it solved the CATC detected wait state! :)
... but it doesn't seem like you needed to change EHCI at all. As I know, since the driver was happily streaming for me too!
- Dave
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
