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. > 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. 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
