Re: [RFT & RFC] USB: Fix USB device disconnects on resume.

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

 



On Fri, Aug 23, 2013 at 10:43:19AM -0400, Alan Stern wrote:
> On Wed, 21 Aug 2013, Sarah Sharp wrote:
> 
> > Background
> > ----------
> > 
> > The USB 2.0 specification, section 7.1.7.7, says that upon device remote
> > wakeup signaling, the first active hub (which is often the roothub) must
> > rebroadcast the resume signaling for at least 20 ms (TDRSMDN).  After
> > that's done, the hub's suspend status change bit will be set, and system
> > software must not access the device for at least 10 ms (TRSMRCY).
> > 
> > It turns out that TRSMRCY is a *minimum*, not a *maximum*, according to
> > Table 7-14.  That means the port can actually take longer than TRSMRCY
> > to resume.  Any attempt to communicate with the device, or reset the
> > device, will result in a USB device disconnect.
> 
> By the way, I just noticed your Google+ posting about this.  I think 
> you (and perhaps the engineers you spoke with) may have misunderstood 
> what Table 7-14 means when it lists 10 ms as the _minimum_ value for 
> TRSMRCY.
> 
> This delay value is a requirement on the OS.  The host system must not
> access the device until at least 10 ms after the resume is complete.  
> The system can wait longer than that if it wants -- that's why 10 ms is
> a minimum.  It just has to avoid accessing the device sooner.
> 
> A _minimum_ value on the host side translates into a _maximum_ value on 
> the device side.  The device can safely assume that it can spend up to 
> 10 ms getting back into shape after a resume, but no more.  After 10 
> ms, the host may try to communicate with it.

After re-reading the spec, I agree with your analysis.  However, the
fact that chipset designers misinterpreted the spec means there may be
hardware out there that needs a longer timeout.  The spec should have
been normative on both the software and the hardware, saying something
like:

"The USB System Software must provide a 10 ms resume recovery time
(TRSMRCY) during which it will not attempt to access any device
connected to the affected (just-activated) bus segment.  The host
controller and device must be ready for communication after the resume
recovery time (TRSMRCY) expires."

I have heard reports of USB devices disconnecting from the bus and
reconnecting after remote wakeup.  I've personally experienced this with
one of my PL2303 USB serial adapters, although it has since died, so I
can't retest.

Another company (whose email I ironically lost due to a failed transfer
to a USB 3.0 backup drive) had bus traces showing the root cause of a
disconnect on resume from remote wakeup.  Occasionally, the host
controller was sending the SoFs too soon on resume, and the device would
interpret it as a low-speed chirp.  The device would disconnect, and
transform from a high speed device to a low speed device.  I don't
think increasing the 10 ms time out will help at all in this case, but
you did ask what USB device disconnect scenarios I've seen.

If users do see device disconnects on remote wakeup resume, we should
see if increasing the timeout helps.

> > Then, when the USB core calls into get port status, it transitions the
> > port from the Resume state to the RExit state by changing the port link
> > state to U0.  The xHCI driver will get a port status change event when
> > that transition is complete, but that port status change event is
> > currently ignored.
> 
> The excess delay you observe with xHCI is the time spent in the RExit
> substate?  That probably should not be counted as part of the TRSMRCY
> period.  It's hard to say for certain, because TRSMRCY is described
> only in the USB-2 spec and not in the xHCI spec, and vice versa for
> RExit.  Still, it's reasonable to assume that the TRSMRCY period should
> begin when the port changes back to U0, not when it leaves the RESUME
> state and enters RExit.
> 
> So in the end this appears to be a simple bug in xhci-hcd.  The
> Get-Port-Status request that terminates the resume signalling should
> wait until the port goes back into U0 (which agrees with what you have
> already decided, of course).  ehci-hcd does something similar:
> 
> 			/* stop resume signaling */
> 			temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
> 			ehci_writel(ehci, temp, status_reg);
> 			clear_bit(wIndex, &ehci->resuming_ports);
> 			retval = ehci_handshake(ehci, status_reg,
> 					PORT_RESUME, 0, 2000 /* 2msec */);
> 
> The ehci_handshake call busy-waits until the controller turns off the
> PORT_RESUME bit, which happens when the port has switched to a
> high-speed idle.  It's supposed to take no more than 2 ms but hopefully
> is a lot faster.  (Hmmm, maybe the private lock should be dropped
> during this handshake...)

Ah, so there is an analogous issue in EHCI.  Basically, the EHCI driver
waiting for the PORT_RESUME bit to be clear is equivalent to the xHCI
driver waiting for the port to enter U0.  I agree that this seems like
an xHCI driver issue, and I'll fix it in the driver.

Sarah Sharp
--
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