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. 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. In contrast to that, the device works with Windows (7). The strategy for Windows is to fallback to lower 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? On Wed, Dec 23, 2009 at 5:36 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > http://bugzilla.kernel.org/show_bug.cgi?id=14841 >> > >> > Summary: unable to enumerate USB device on port X after >> > suspend/resume > >> It's a regression from 2.6.31 (I assume?) to 2.6.32. No, I have seen this behaviour with 2.3.31 too. > Is it a regression? Did this work okay under 2.6.31? Can you provide > a usbmon trace showing the successful behavior under 2.6.31? Alan, you have seen this trace already. I posted a successful SD card probe here involving the capacity-is-wrong-bug http://article.gmane.org/gmane.linux.scsi/56469 I guess this reader is nothing but broken. 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... -- Fruhwirth Clemens http://clemens.endorphin.org
Attachment:
not-attached-before-boot-loader_detached-after-boot_reattached
Description: Binary data
