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() ? Regards Oliver -- 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
