On Sun, 27 Dec 2009, Clemens Fruhwirth wrote: > Hello Alan, hello Andrew, > > After some more probing, I found that my initial conclusion that this > is related to suspend/resuming has been totally wrong. First, the > device works only under a USB 1.1 root despite the USB description > telling me that this is a USB 2.0 device. In theory there's nothing wrong with that. It's perfectly valid for a USB-2.0 device to run only at full speed, not at high speed. Of course, in your case it's more likely that this indicates the device is somehow broken. Have you posted the "lsusb -v" output for the device? It should indicate (if you're using a recent version of lsusb) at what speeds the device is meant to run. > The symptoms observed come > merely from the fact that connecting/reconnecting after boot tries to > attach the device under a USB 2.0 root. I have not yet found out, why > after a cold boot the device runs at fullspeed and not highspeed, (USB > handoff?). The suspend/resume cycle triggers a "connect" (or > reconnect) and therefore I get the same symptoms when doing a > reconnect by hand without sleeping inbetween. There's the question of why it works during boot but not afterward. This could be caused by the timing of events. During boot lots of other stuff is going on, and it could cause the USB initialization sequence to be delayed. That in turn could easily affect the outcome if the device is broken. > In contrast to that, the device works with Windows (7). The strategy > for Windows is to fallback to lower speed. Linux does the same thing. But it can't when the device disconnects and then reconnects, which is what happened in your logs. Each reconnect is handled independently, starting fresh at high speed. > I can force the device to USB 1.1 by using "companion" of the EHCI > driver, where I can force handoff to the companion controller (thanks > Alan for this feature) so I can live without any changes. However, I'm > wondering whether an automatic fallback is a good idea for devices > that fail to enumerate? We already do it, subject to the limitation described above. > I attached a log where I did the following: > > Boot with device detached until the bootloader (so that I don't the > BIOS initialization can't screw things up) > Attach device > Boot into the kernel > Start usbmon (device works) - here the trace starts > Disconnect/Reconnect device > Devices doesn't connect properly after timestamp 20588... The usbmon trace doesn't contain any information about the reconnect. Can you do the same thing again, but using the 0u file instead of 2u? 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
