On Sun, 8 Jul 2012, Octavio Alvarez wrote: > >> On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern > >> <st...@rowland.harvard.edu> > >> wrote: > >> > >> >> roothub.portstatus [4] 0x00000303 LSDA PPS PES CCS > >> >> roothub.portstatus [5] 0x00000303 LSDA PPS PES CCS > >> >> roothub.portstatus [6] 0x00000101 PPS CCS > >> > > >> > That's normal, except for the status of port 6 (which actually is port > >> > 7, since we normally count ports starting from 1). The port shows > >> > Current Connect Status, so something is connected to it -- but what? > >> > >> It looks like it was my pendrive. Disconnecting the mouse and keyboard > >> cleared CCS on [4] and [5] (not necesariliy in that order). > >> > >> Removing my pen drive cleared CCS on [6]. > > > > Okay, that explains that. More or less. Is this an old USB-1.1 pen > > drive? If it is USB-2.0 then I would expect it to connect to the EHCI > > controller, not the OHCI controller. > > I don't know... Is there a way to know that? The device is a > > Bus 001 Device 011: ID 0781:5406 SanDisk Corp. Cruzer Micro U3
That doesn't mean much by itself. But the lsusb output you included confirms that the pen drive was running at high speed -- which means that it should never have been connected to the OHCI controller at all. Another mystery. It appears that your computer's USB hardware is kind of funky. > Does it make sense to think that some ports are OHCI and some are > EHCI, particularly if some of them are on the back and some on the > front? No, not really. All the ports should be connected to both controllers. You can check the dmesg log to make sure that they have the same number of ports. > > The suspending part is normal. The resuming part is not... > > > >> [ 181.394398] usb usb2: usb resume > >> [ 181.394403] ohci_hcd 0000:00:0b.0: wakeup root hub > >> [ 181.394426] usb usb1: usb resume > >> [ 181.394430] ehci_hcd 0000:00:0b.1: resume root hub > >> [ 181.428035] ehci_hcd 0000:00:0b.1: port 6 low speed --> companion > > > > That shouldn't have happened. It's not actually _wrong_, but it > > indicates that the USB controllers did not maintain their states > > properly while the system was suspended. > > Considering that this happens while the system is already resuming, > do you think is in some way related with the bug? Yes, I do. It happened during resume because of something that went wrong during suspend. That same something could easily be responsible for the immediate wakeup. > > Just out of curiosity, what happens if you suspend with the mouse and > > keyboard unplugged, i.e., no USB devices attached at all? (To > > forestall possible questions, you run a little shell script that sleeps > > for 10 seconds, during which you unplug the keyboard and mouse, and > > then initiates a system suspend.) > > I'm using the power button to suspend and resume, so this test is > actually easy. > > It's weird, but without K & M connected, even with the pendrive > connected, the system suspends! (The keyboard leds go off and all, > though) It's normal for the LEDs to turn off -- they use more current than is available when the keyboard is suspended. What happens if you unplug only the keyboard, or only the mouse? Alan Stern -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.44l0.1207082018260.16235-100...@netrider.rowland.org
