On Fri, Nov 11, 2011 at 03:25:18PM -0500, Alan Stern wrote: > On Fri, 11 Nov 2011, Sarah Sharp wrote: > > > Speaking of device suspend, have you ever found that whether USB device > > suspend and resume works depends on which system the device is attached > > to? > > I haven't seen that happen. Ok. I think I might have seen this phenomenon on some systems, but I never really investigated it. My only USB device that was sometimes flaky on resume (a really old PL2303 serial adapter) finally bit the bullet and just won't enumerate anymore. > > I've had some slides forwarded to me that have some interesting > > electrical captures that show that if a host controller is too fast in > > enabling SOFs after resume signaling ends (where too fast is < 1us), the > > device doesn't have time to enable its high speed terminations. > > Section 7.1.7.7 seems to say that devices have 1.3 us to enable their > high-speed terminations. (Actually it says "they must transition back > to high-speed operation, without arbitration, within two low-speed bit > times of the K to SE0 transition". That's an odd way of putting it, > but since a low-speed bit lasts for 2/3 us, the meaning is clear.) If > the host controller starts sending SOFs before this then presumably > it's not compliant -- although the spec doesn't say that the upstream > port must wait at least this long. A peculiar omission. It may be that they just didn't think about the effect of SOFs. I know the USB-IF certification folks don't have a test for selective suspend, since that requires Windows drivers to support it. They do have a test for system suspend and resume, but devices would probably get reset after being resumed and the SOF issue would have been missed. > > The SOF > > ends up looking like a device disconnect, and it's possible that the > > host might then report it as a low speed device. That sounds pretty > > similar to the resume fails that we've been assuming are really the > > device's fault. > > > > The experiments that the people did showed that some host controllers > > were pretty consistent about the minimum time between the end of resume > > and the start of the SOF, while others were pretty random, and the SOF > > would sometimes fall in the 1us window, causing random disconnects. > > Have you seen devices that sometimes worked after resume and sometimes > disconnected, apparently at random? Yes, I have seen some devices that survived one resume, and then disconnected on another resume, or showed up as a low speed device. I can't remember which ones, other than the serial adapter I mentioned. Time to dig around in my USB device box, I suppose. > > This was sort of a shift in thinking for me, since we've been blaming > > "bad devices" for years without wondering if the host controller > > behavior was also causing resume failures. > > You always have to remember that communication involves two endpoints > plus an intermediate connector. Problems can affect any of the > components. My favorite example was a USB drive that didn't work in a > certain setup, but did start working if I changed either the host > controller, the USB cable, or the drive. > > Was anyone able to find out if some brands of controllers were > consistently better or worse than others? It actually seemed to be system specific. Some laptops one host controller version would have random delays, while other laptops with the same host controller would have a consistent 6us delay before starting SOFs. So I don't think we can draw any conclusions about one brand of controllers being better than another. 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
