So David, Greg, can you use that technical description, and an end-user description of: If you are having problems with devices or hub ports resetting when you start using a USB audio or video (Isochronous) device, this patch may help. On Mon, Apr 20, 2009 at 10:52 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 20 Apr 2009, Dan Streetman wrote: > >> Well, the theoretical problem is that the bug could delay a transfer >> long enough that it doesn't finish in time for the TT to transfer the >> data back in the last scheduled CSPLIT for the transfer. I suspect >> this would look like, when a user starts using an isoc device like USB >> audio or video, another device that was already connected stops >> working. I have not seen this problem myself. >> >> The failure report from James is that when he starts using a USB audio >> device, his mouse gets port reset. James, did you see any "-110" or >> "timeout" errors before the port reset? I would expect timeout >> errors, not a port reset (I think the EHCI driver handles all the >> CSPLITs failing as a timeout error, right?). There may be code that >> does a port reset on too many timeout errors to try to recover a >> device. > > Yes, the usbhid driver does that. > > You can describe the symptom this way: > > Without this patch, the driver won't check that the last fully-occupied > uframe for a new split transaction was vacant beforehand. This can > lead to a situation in which the first 188 bytes of a 192-byte > isochronous transfer are scheduled in the same uframe as an existing > interrupt transfer. The resulting schedule looks like this: > > uframe 0: 188-byte isoc-OUT SSPLIT, 8-byte int-IN SSPLIT > uframe 1: 4-byte isoc-OUT SSPLIT > > The SSPLITs are intermingled, causing an error in the downstream hub's > TT. > > Alan Stern > > -- 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
