Re: additional debug output for autosuspend in cdc-ether

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux