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. > 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. > 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? > 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? > I don't think there's anything we can do, software-wise, to fix this > issue, but it's an interesting thing to consider when distros decide > whether to ship a udev rule that turns on auto-suspend for a particular > device. For these devices that are slow to enable terminations, resume > might work on some systems but fail on others. True. And also true that this is a hardware issue beyond our control. 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
