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
