> > 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. 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? > > After a suspend/resume cycle my SD card fails to work (attached over > > usb-storage). But it works okay before you suspend/resume? Was the card reader plugged in during the suspend? What happens if you unplug the reader after resuming and then plug it in again? > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/256767 has a lengthly > > "me-too" list of people affected. So that bug seems very real to me. Also it is > > not harmless as some people claim, the device fails to work for me unless I > > cold-boot without uswsusp-resuming. The people chiming in on that bug report actually described a wide variety of different kinds of failures. Some of them have been fixed and some haven't. > > I found the following message interesting: > > http://lkml.org/lkml/2008/10/24/209 > > and it makes me speculate that this "EHCI most be loaded before UHCI/OHCI" > > condition is violated when (re-)initializing the USB ports from a cold-boot > > resume. If you read that log message more closely you'll see that it says "ehci_hcd should always be loaded before uhci_hcd and ohci_hcd". _Should_, not _must_. Loading the drivers in the wrong order can give rise to one or two "unable to enumerate" messages, but not an unending stream of them. > > That is what's going on my usbmon port for that particular USB port: > > > > eb302780 964861293 S Ci:2:001:0 s a3 00 0000 0002 0004 4 < > > eb302780 964861295 C Ci:2:001:0 0 4 = 01050100 > > eb302780 964861297 S Co:2:001:0 s 23 01 0010 0002 0000 0 > > eb302780 964861301 C Co:2:001:0 0 0 > > eb302780 964861303 S Ci:2:001:0 s a3 00 0000 0002 0004 4 < > > eb302780 964861306 C Ci:2:001:0 0 4 = 01050000 > > eb302780 964889554 S Ci:2:001:0 s a3 00 0000 0002 0004 4 < > > eb302780 964889559 C Ci:2:001:0 0 4 = 01050000 > > eb302780 964920138 S Ci:2:001:0 s a3 00 0000 0002 0004 4 < > > eb302780 964920148 C Ci:2:001:0 0 4 = 01050000 > > eb302780 964950136 S Ci:2:001:0 s a3 00 0000 0002 0004 4 < > > eb302780 964950146 C Ci:2:001:0 0 4 = 01050000 > > eb302780 964980134 S Ci:2:001:0 s a3 00 0000 0002 0004 4 < > > eb302780 964980144 C Ci:2:001:0 0 4 = 01050000 That was a normal debounce. > > eb302780 964980153 S Co:2:001:0 s 23 03 0004 0002 0000 0 > > eb302780 964980156 C Co:2:001:0 0 0 > > eb302780 965032890 S Ci:2:001:0 s a3 00 0000 0002 0004 4 < > > eb302780 965033076 C Ci:2:001:0 0 4 = 03051000 That was a successful port reset. > > f6c62b80 965033101 C Ii:2:001:1 0:2048 1 = 04 > > f6c62b80 965033110 S Ii:2:001:1 -115:2048 4 < This indicates that when the reset was over, something happened -- probably a disconnect event. It's possible that the reader wasn't able to reset correctly. > > eb302780 965087074 S Co:2:001:0 s 23 01 0014 0002 0000 0 > > eb302780 965087081 C Co:2:001:0 0 0 > > eb302780 965087091 S Ci:2:000:0 s 80 06 0100 0000 0040 64 < > > eb302780 965091083 C Ci:2:000:0 -71 0 > > eb302780 965091093 S Ci:2:000:0 s 80 06 0100 0000 0040 64 < > > eb302780 965095208 C Ci:2:000:0 -71 0 > > eb302780 965095216 S Ci:2:000:0 s 80 06 0100 0000 0040 64 < > > eb302780 965099333 C Ci:2:000:0 -71 0 These -71 errors confirm that the device was not connected properly. > > eb302780 965099341 S Co:2:001:0 s 23 03 0004 0002 0000 0 > > eb302780 965099344 C Co:2:001:0 0 0 > > eb302780 965150135 S Ci:2:001:0 s a3 00 0000 0002 0004 4 < > > eb302780 965150451 C Ci:2:001:0 0 4 = 00011100 And so does this port status value. 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
