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. The disconnect occurs so quickly after the resume signalling is turned off (it gets turned off during the hub_port_status() call following the 25-ms delay) that there has to be a causal link. For example, the controller may have detected a disconnect while sending the first SOF packet after the end of the resume, if the device didn't switch off its D+ pullup and enable its high-speed terminations quickly enough. It's supposed to do this within 2 low-speed bit times (i.e., 1.667 us) of the end of the resume signal. If it takes longer than 125 us, the host will think there was a disconnect. Since this critical time begins when the resume signal ends, I doubt that lengthening the resume period will help. But who knows? 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