On Thu, 7 Jul 2005 [EMAIL PROTECTED] wrote:
> I've not been posting a lot since my current mailer config seems
> to be making linux-usb-devel reject posts to the list; happened
> rather suddenly about a week ago, unclear what changed, so I've
> been lazy tracking it down.
>
> So I suspect this won't get to the list ... though with luck it'll
> get to both of you!
I got it okay. The only obvious difference with respect to your earlier
emails is in the envelope sender. This one was from
<[EMAIL PROTECTED]> whereas earlier ones were
from <[EMAIL PROTECTED]>. Of course, email blacklisting may play a part.
> In response to the question: there's only one place in the source
> code which reports that error. Are the comments there unclear?
Here's what that region says:
now = readl (&ehci->regs->frame_index) % mod;
/* when's the last uframe this urb could start? */
max = now + mod;
Those two values are pretty clear.
/* typical case: reuse current schedule. stream is still active,
* and no gaps from host falling behind (irq delays etc)
*/
if (likely (!list_empty (&stream->td_list))) {
start = stream->next_uframe;
I suppose that's when the first TD for this URB is supposed to be sent.
if (start < now)
start += mod;
Meant to handle sequence-space wrap-around? Does this handle actual
overruns correctly?
if (likely ((start + sched->span) < max))
goto ready;
I don't understand this at all. What's sched->span? Does that simply
mean the requested time is not so far in the future that you can't add it
to the schedule yet?
/* else fell behind; someday, try to reschedule */
status = -EL2NSYNC;
goto fail;
}
And this is the failure path of the unclear test. All I get from the
comment is that something fell behind something else. It's not clear
who was late, and the "try to reschedule" part is confusing too. How can
ehci-hcd try to reschedule an ISO stream that's supposed to follow a
strict sequence of transmission times?
> Basically the system fell behind in processing the ISO requests,
> I suspect because your driver didn't keep the queue deep enough to
> cover the IRQ latencies. Keep a few more URBs queued -- or maybe
> just bigger ones -- and the issue ought to go away.
If I understood the previous test right, the caller tried to submit an URB
for too far in the future. This doesn't jibe with your explanation.
Alan Stern
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
