On Thu, 26 Aug 2010, Ming Lei wrote: > > Here's a scenario to consider. Suppose there are no isochronous > > transfers going on, but there is a long-period interrupt transfer and > > the completion handler always resubmits. > > > > Suppose two successive URBs complete exactly one second apart (since > > the period is large this is not unlikely), and let N be the frame list > > entry in which the two transactions occurred. Finally, suppose that > > IRQ latency causes the interrupt handler for the second completion to > > be delayed by 1 ms. > > > > Then during the first IRQ the CPU will read N from the frame counter > > and during the second it will read N+1. As a result, while processing > > the second IRQ, the big loop in scan_periodic() will look only for > > events occurring during frame N+1, so it won't see the URB that > > completed during frame N. > > Yes, it is really a corner case. > > > > > It seems we should insure that scan_periodic() checks at least the > > last SCHEDULE_SLOP frames if the frame list has wrapped since the last > > scan. > > Another way, we may enable 'Frame List Rollover' irq to fix the > case above if interrupt or iso transfers are to be scheduled. In > the irq handler for 'Frame List Rollover' , scan_periodic can be > called to scan periodic list and ehci->next_uframe will be updated. I don't like that idea very much. It would mean getting extra interrupts between one and four times per second, and doing a bunch of unnecessary work each time. 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
