On Mon, 23 Nov 2009, Alan Stern wrote: > On Mon, 23 Nov 2009, Oliver Neukum wrote: > > > Am Montag, 23. November 2009 18:43:09 schrieb Alan Stern: > > > 56 milliseconds later (the mdelay statement you added), we see the > > > status resport. "CSC" stands for "Connect Status Changed", meaning > > > there was a disconnection. And the hub driver realizes that something > > > went wrong because it tries to carry out a reset-resume -- and this > > > time it succeeded with not XactErr problem, thanks to the mdelay. > > > Unfortunately the cdc-acm and cdc-ether drivers don't have reset-resume > > > handlers, so the drivers were unbound and rebound anyway. > > > > On second thought, reset_resume wouldn't help as a disconnection > > is bound to cut the current connection to the net. > > > > > In the end, the underlying problem is the disconnection. It caused > > > those XactErr messages and the reset-resume. I don't know why the > > > disconnect occurs, or why it occurs only some of the time. Maybe your > > > host controller or device hardware (or both!) is slighly out of spec, > > > so that the speed transition works most of the time but not all the > > > time. > > > > Ok, how about cutting even more slack and do some voodoo. > > Can you double the delays in hub.c::usb_port_resume() ? > > Rickard can try it. Lengthening the 10-ms TRSMRCY delay won't make any > difference, because the disconnect occurs during that delay. > Increasing the 25-ms delay before it _might_ help; it's worth a try. Oops, my mistake. I forgot for a moment that we're talking about a remote wakeup, not a normal resume. For remote wakeup, the relevant time delay is in ehci_hcd.c's ehci_irq() routine. It is given by the assignment to ehci->reset_done[i] in the "if (status & STS_PCD)" block of code. When the hcd->rh_timer expires, it causes khubd to issue the Get-Port-Status request that turns off the resume signal. 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