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. On Fri, Apr 17, 2009 at 8:26 PM, David Brownell <david-b@xxxxxxxxxxx> wrote: > On Friday 17 April 2009, Dan Streetman wrote: >> The current EHCI TT scheduler checks any periodic transfers greater than 1 >> uframe to make sure each of its fully-used uframes is empty, but there is a bug >> that causes it to not check the last fully-used uframe. This patch removes the >> unneeded -1 to fix that bug, so the scheduler does check each fully-used uframe >> to verify that it is empty before scheduling the transfer. > > That description doesn't quite capture *why* this is a problem. > Like what's the observed failure mode ... how would someone know > they want this patch, or should expect it to solve their issue? > > I'm sure I saw a description of an actual failure caused by this... > > > -- 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
