On Friday 27 April 2007, Mike Nuss wrote: > > In our environment I can reproduce it a couple of times a day by sending > a ton of data from our devices. A device will seem to stop sending data > (this is probably the start of the "bad condition" where INTR_SF never > happens), and if I then unplug the device, the bug shows up during the > cleanup.
That matches the behavior I saw too ... don't recall if it was IN data (as in your case) or OUT or both, but I do recall INTR_SF lossage following other problems. It made me suspect that the relevant silicon had some issues with high load. > > ISTR this bug dating from back in the 2.4 days. Happens very > > intermittently, > > and never (any longer) to me ... after lots of driver fixes (little > > races) > > in the 2.5.early days, I stopped being able to reproduce it. > > Yes, we first encountered it in 2.4 and upgraded our platform to 2.6 and > ported the device driver in hopes it had been fixed. It seems to behave > "better" in 2.4, in that it doesn't lock up the host controller driver, Beware of memory corruption though ... ISTR seeing that on these code paths, because the controller wasn't quite as dead as it acted. > > The expected interrupt never appears. INTR_SF is supposed to happen > > every millisecond. > > Is it every millisecond regardless of bInterval? Unrelated to bInterval; SF means Start Frame (every millisecond). > > Someone who can reproduce this bug should try to fix it... > > > > - Dave > > Yes, please ;) I'd be happy to look at it myself, since I seem to be > alone in being able to reproduce it. But I'm obviously still pretty new > to the kernel USB stack. Yeah. Well, at some level once you notice that INTR_SF lossage, I thik the only possible recovery is to reset the controller and then restart everything from scratch (re-enumerate etc). Resetting should be easy; so maybe all you'd need to do is call ohci_restart() in a task context. One other thing I'm slightly curious about: whether the interrupt deferral mechanism (TD_DI_SET) affects this. Try disabling it; the difference _should_ be only a significant (up to 6x) increase in the number of IRQs you get. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
