On Mon, Aug 26, 2013 at 10:45:30AM -0700, Sarah Sharp wrote: > On Thu, Aug 22, 2013 at 02:55:07PM -0700, Greg KH wrote: > > On Thu, Aug 22, 2013 at 02:49:07PM -0700, Sarah Sharp wrote: > > > On Thu, Aug 22, 2013 at 10:42:49AM -0400, Alan Stern wrote: > > > > On Wed, 21 Aug 2013, Sarah Sharp wrote: > > > > > > > > > Possible fixes > > > > > -------------- > > > > > > > > > > The USB core obviously needs to be changed to check the port status > > > > > after the TRSMRCY timeout, and continue to wait if the port is still in > > > > > the resuming state. I will have to study the EHCI port status diagrams > > > > > in detail to figure out how the USB core can do this. > > > > > > > > As far as EHCI is concerned, this is a non-problem. The closest > > > > analogy to the RExit->U0 transition is in the description of the Force > > > > Port Resume bit (bit 6) in Table 2-16 of the EHCI spec, where it says > > > > that the host controller must complete the transition to the high-speed > > > > idle state within 2 milliseconds of software setting the bit to a zero > > > > (which happens when the hub driver does its Get-Port-Status call). > > > > > > > > Thus, as soon as the TRSMRCY delay is finished, the device and the port > > > > are supposed to be ready. In fact, the hardware doesn't provide any > > > > means of telling whether they are ready or not. > > > > > > Well, shoot, I thought I had solved world hunger, or at least USB power > > > management issues. :) > > > > > > So basically it sounds like this is an xHCI specific issue, and probably > > > not the root cause of the USB device disconnects we see under EHCI > > > hosts. I guess the xHCI hardware engineers just assumed software would > > > always wait for the interrupt from the port status change event, rather > > > than using a simple 10 ms timer. I bet they didn't even realize that > > > that the transition took longer than 10ms, because Windows waited for > > > the port status change event. > > One last thought on this note: We know Windows doesn't have high-res > timers, and Arjan says asking for a 10 ms delay will produce a delay > around 17 ms. Since Linux is busy waiting, we may be communicating with > the device sooner than Windows does. What does Windows do for this type of thing? How long do they wait before reporting an error? We probably need to do the same as they do, no matter what the spec says. thanks, greg k-h -- 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
