On Tue, 10 Aug 2010, Alessio Sangalli wrote:
> Further investiagtion with the trace tool shows that the execution gets
> "stuck" in the for loop in ehci-sched.c, drivers/usb/host/ehci-sched.c,
> the following code:
>
>
> // FIXME: this assumes we won't get lapped when
> // latencies climb; that should be rare, but...
> // detect it, and just go all the way around.
> // FLR might help detect this case, so long as latencies
> // don't exceed periodic_size msec (default 1.024 sec).
>
> // FIXME: likewise assumes HC doesn't halt mid-scan
>
> if (now_uframe == clock) {
> unsigned now;
> if (!HC_IS_RUNNING (ehci_to_hcd(ehci)->state)
> || ehci->periodic_sched == 0)
> break;
> ehci->next_uframe = now_uframe;
> now = ehci_readl(ehci, &ehci->regs->frame_index) &
> (mod - 1);
> if (now_uframe == now)
> break;
> /* rescan the rest of this frame, then ... */
> clock = now;
> clock_frame = clock >> 3;
> if (ehci->clock_frame != clock_frame) {
> free_cached_lists(ehci);
> ehci->clock_frame = clock_frame;
> }
> } else {
> now_uframe++;
> now_uframe &= mod - 1;
> }
>
>
> This loops keep executing several hundreds of times, for almost 2
> milliseconds while interrupts are globally disabled, and basically no
> action is really performed.
Note: This isn't a loop. It's the last part of the code in a larger
loop.
The number of times the larger loop executes depends on how often a
periodic URB completes. That might be hundreds of iterations, but if
it is then most of the iterations should be very fast. For example, if
there's an isochronous URB with 10 packets and a period of 64 uframes,
then the loop would execute 640 times but only 10 of those iterations
would do any work. This shouldn't take 2 milliseconds.
> Would you be able to suggest any kind of further debug or experiment I
> may try? Or give a rough explanation what *should* happen here?
Can you find out how much work is done on each loop iteration? For
example, how many times does the "while (q.ptr != NULL) {" inner loop
run? How many times does the code call intr_deschedule, itd_complete,
or sitd_complete? How many times does the "goto restart" line execute?
And finally, how many times does the "if (now_uframe == now)" test
fail?
It might turn out that some of the itd_complete or sitd_complete calls
are very slow.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
