David Brownell wrote: > > The worst case should be seven frames (maximum time any WDH irq would > be deferred) and two WDH irqs. That would even cover that mostly-safe > assumption that multi-TD interrupt transfers aren't happening (they're > pretty rare with full speed hardware).
I know now that the problem is caused by not waiting long enough. I've changed the patch and so far, waiting a single extra frame is enough - I've instrumented it so that I can see that the state was "bad" after the first SOF, but was cleared on the next SOF. I'll run extended tests to verify that this is indeed sufficient. If so, the delay could still be bumped up to 7 frames to be safe without any additional performance hit. Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
