Sarah Sharp wrote: > On Tue, Oct 20, 2009 at 10:00:29AM +0200, Clemens Ladisch wrote: > > Sarah Sharp wrote: > > > Testing for the broken Intel chipset would be a good idea, yes. > > > However, it means way more bureaucratic headache for me, since I would > > > have to get committee clearance to do so. > > > > Then just test for vendor==Intel. I don't think it would be a good > > idea to let the USB scheduling on your competitor's host controllers > > suffer because one of your chipsets has a bug. > > This bug should never be hit by any device driver that wants to keep the > bus busy. Sorry, I assumed it would apply to high-speed transfers, too. (I was thinking of a high-speed audio data ring buffer that is shorter than the IST, but those transfers wouldn't succeed anyway, even without the bug.) > > > Also, the engineering team wanted this to be a generic fix because > > > they thought it would cause problems in future designs. They read the > > > EHCI spec as saying that software should not attempt to schedule > > > within the IST. > > > > However, the scheduling is inherently racy; in the absence of a hard > > real-time system it is impossible to guarantee that a transfer slips > > inside the IST window. I can easily imagine a situation where the slop > > of two microframes is not enough because of a SMM interrupt happening > > at the wrong time. > > Yes. So the user may experience a blank webcam occasionally. If they > unplug and replug in the device, it may work. If you have a suggestion > to make that race disappear or make the time it can occur in shorter, > then please let me know. :) Given that the stall ends at a control transfer, you could regularly poll the device with same harmless control message. (Well, "harmless" is relative, depending on the quality of the device's firmware ...) Best regards, Clemens -- 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
