On Wed, 25 Nov 2009, Oliver Neukum wrote: > Am Mittwoch, 25. November 2009 16:16:32 schrieb Rickard Bellini: > > I think you are on to something here. Testing the last correction below, > > and including the extra msleep(50); before the usb_mark_last_busy(udev); > > in the remote_wakeup() function within hub.c. I have not seen any XactErr > > or USB resets triggered by remote wakeup in over 5000 cycles. I will need > > to keep running until I hit something around 10000 cycles until I can > > judge it stable. > > Hello, > > this looks good. I am afraid you will have to determine a sensible timeout. > 200ms is an outrageous time for this and hopefully much too long. > Then we'll have to add a quirk for your device. 25 ms might work out. That's what we use for ordinary (i.e., not remote-wakeup) resumes. And the msleep(50) in remote_wakeup() should not be needed. But thinking about it made me realize there is a bug in usb_port_resume(). The two lines /* TRSMRCY = 10 msec */ msleep(10); should come just after the SuspendCleared: label, not inside the "if" block before the label. Try leaving out the msleep from remote_wakeup() and moving the msleep in usb_port_resume(), while keeping the 200-ms delay in ehci_irq(). If that is okay, then experiment with reducing the 200 to 25 or various values in between. 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
