On Tue, Oct 20, 2009 at 10:00:29AM +0200, Clemens Ladisch wrote: > Sarah Sharp wrote: > > On Mon, Oct 12, 2009 at 10:36:52PM -0400, Alan Stern wrote: > > > You might want to make this change as specific as possible, so that > > > existing controllers will see the same behavior as before. That means > > > testing for the bad controller type and testing for full-speed > > > transfers. > > > > 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. The only way to hit this is to resubmit the same isoc URB that just completed in the driver's URB completion handler, without another transfer already in the pipe. The webcam drivers I modified submitted 3 or more URBs at a time, and resubmitted each one as they came back, so they would never hit this bug. It was certainly not my intent to give the users a bad Linux experience on non-Intel systems. I just don't think anyone is likely to hit this case. ICH9 has been out for two years now, so we should have heard people complaining about blank video from webcams or no sound from USB speakers if this was a common case. But I'll go rev the patch one more time. I'll have to confirm the new EHCI controller still has an 0x8086 PCI vendor ID, and wait until Thursday to test the patch since I left my isoc devices at work. Unless you could test the patch? > > 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. :) The Intel chipset team is aware of this bug now, so hopefully they will fix it. Sarah -- 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
