Hi all,
I use the IRQ transfer in high speed. qh->period=1 (frame).
As long as the qh can be reused everything is fine...
If not then we end up here: This loop loops virtually forever with period=1:
It seems that a periodic QH can usually be re-used, then! And that few folk use more than one period=1 urb.
frame = qh->period - 1; do { for (uframe = 0; uframe < 8; uframe++) { status = check_intr_schedule (ehci, frame, uframe, qh, &c_mask); if (status == 0) break; } } while (status && --frame);
... as the decrement happens too early. Seems to me so. What about:
(status && frame--)
That is, near the top of qh_schedule? Seems right to me; if that one frame was filled, it'd take a long time (with irqs blocked) to report that failure.
That's a good find.
/Bernd
P.S.: However, this does not solve my problem that just now only one INT transfer per frame is allowed. Is this right, Dave?
Yes and I'm surprised there seem to have been no trouble reports for issues there, yet.
I have a patch in the works to turn the periodic INT schedule into a sparse tree. Like OHCI, but with TT scheduling, high bandwidth, and microframes it was easier to use a first fit scheduling policy instead of best fit (no "load balancing").
Should I dig that patch up? I think the last testing status was that it worked fine except for an "unlink from middle of hw list" oops that I could trigger in certain sequences of device unplugs.
- Dave
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
