FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 07-08-2012, 02:40 PM
Alan Stern
 
Default Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51

On Sat, 7 Jul 2012, Octavio Alvarez wrote:

> On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern <stern@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.

> FYI, bisecting and other testing was done pretty much without my
> pendrive all the time.

Good. The fewer possible sources of confusion, the better.

> I just tested suspend, just for the sake of it, and it still
> wakes up right after sleep.
>
> > Can you post a complete dmesg log showing bootup with CONFIG_USB_DEBUG
> > enabled?
>
> Sure. This is it, up to second 178 (last msg is in 81), before pushing the
> suspend button.
...

Pretty much normal.

> This is the continuation of the previous dmesg, starting on second 178,
> when I pressed the power button.
>
> (done without my pen drive)

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.

> [ 181.472053] hub 2-0:1.0: hub_resume
> [ 181.472076] ohci_hcd 0000:00:0b.0: GetStatus roothub.portstatus [4] =
> 0x00030301 PESC CSC LSDA PPS CCS
> [ 181.472082] hub 2-0:1.0: port 5: status 0301 change 0003
> [ 181.472100] ohci_hcd 0000:00:0b.0: GetStatus roothub.portstatus [5] =
> 0x00030301 PESC CSC LSDA PPS CCS

These messages are indications of the same problem.

> [ 181.472105] hub 2-0:1.0: port 6: status 0301 change 0003
> [ 181.524028] ehci_hcd 0000:00:0b.1: GetStatus port:6 status 003402 0
> ACK POWER OWNER sig=k CSC
> [ 181.540030] hub 1-0:1.0: hub_resume
> [ 181.540040] ehci_hcd 0000:00:0b.1: GetStatus port:1 status 001020 0
> ACK POWER sig=se0 OCC
> [ 181.540051] ehci_hcd 0000:00:0b.1: GetStatus port:2 status 001020 0
> ACK POWER sig=se0 OCC
> [ 181.540061] ehci_hcd 0000:00:0b.1: GetStatus port:3 status 001020 0
> ACK POWER sig=se0 OCC
> [ 181.540071] ehci_hcd 0000:00:0b.1: GetStatus port:4 status 001020 0
> ACK POWER sig=se0 OCC
> [ 181.540086] ehci_hcd 0000:00:0b.1: GetStatus port:7 status 001020 0
> ACK POWER sig=se0 OCC
> [ 181.540095] ehci_hcd 0000:00:0b.1: GetStatus port:8 status 001020 0
> ACK POWER sig=se0 OCC

These messages are highly suspicious. They indicate a low-level
hardware problem in the wiring of the USB controllers or support
components.

I won't go into further detail. The remaining events all seem to flow
from these underlying problems.

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.)

Also, what happens if you unload ehci-hcd before suspending (with the
keyboard and mouse plugged in as normal)?

Alan Stern




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.LNX.4.44L0.1207081025080.9155-100000@netrider.rowland.org">http://lists.debian.org/Pine.LNX.4.44L0.1207081025080.9155-100000@netrider.rowland.org
 
Old 07-08-2012, 05:22 PM
"Octavio Alvarez"
 
Default Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51

On Sun, 08 Jul 2012 07:40:49 -0700, Alan Stern <stern@rowland.harvard.edu>
wrote:


On Sat, 7 Jul 2012, Octavio Alvarez wrote:

On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern
<stern@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

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?


This is the continuation of the previous dmesg, starting on second 178,
when I pressed the power button.

(done without my pen drive)


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?


[ 181.472105] hub 2-0:1.0: port 6: status 0301 change 0003
[ 181.524028] ehci_hcd 0000:00:0b.1: GetStatus port:6 status 003402 0
ACK POWER OWNER sig=k CSC
[ 181.540030] hub 1-0:1.0: hub_resume
[ 181.540040] ehci_hcd 0000:00:0b.1: GetStatus port:1 status 001020 0
ACK POWER sig=se0 OCC
[ 181.540051] ehci_hcd 0000:00:0b.1: GetStatus port:2 status 001020 0
ACK POWER sig=se0 OCC
[ 181.540061] ehci_hcd 0000:00:0b.1: GetStatus port:3 status 001020 0
ACK POWER sig=se0 OCC
[ 181.540071] ehci_hcd 0000:00:0b.1: GetStatus port:4 status 001020 0
ACK POWER sig=se0 OCC
[ 181.540086] ehci_hcd 0000:00:0b.1: GetStatus port:7 status 001020 0
ACK POWER sig=se0 OCC
[ 181.540095] ehci_hcd 0000:00:0b.1: GetStatus port:8 status 001020 0
ACK POWER sig=se0 OCC


These messages are highly suspicious. They indicate a low-level
hardware problem in the wiring of the USB controllers or support
components.

I won't go into further detail. The remaining events all seem to flow
from these underlying problems.

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)


Also, what happens if you unload ehci-hcd before suspending (with the
keyboard and mouse plugged in as normal)?


It doesn't suspend. I tested this a while ago. It's pretty much specific
to ohci_hcd.


Not sure if this is helpful but:

[Sun Jul 08 10:02:31 -0700 -- alvarezp@octavio:~]
$ sudo lsusb -vvvv

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.02
iManufacturer 3 Linux 3.2.0-3-686-pae ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:0b.1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 11
bDescriptorType 41
nNbrPorts 8
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00 0x00
PortPwrCtrlMask 0xff 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Port 7: 0000.0100 power
Port 8: 0000.0503 highspeed power enable connect
Device Status: 0x0001
Self Powered

Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 3.02
iManufacturer 3 Linux 3.2.0-3-686-pae ohci_hcd
iProduct 2 OHCI Host Controller
iSerial 1 0000:00:0b.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 11
bDescriptorType 41
nNbrPorts 8
wHubCharacteristic 0x0002
No power switching (usb 1.0)
Ganged overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00 0x00
PortPwrCtrlMask 0xff 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0303 lowspeed power enable connect
Port 6: 0000.0303 lowspeed power enable connect
Port 7: 0000.0100 power
Port 8: 0000.0100 power
Device Status: 0x0001
Self Powered

Bus 002 Device 009: ID 046d:c05a Logitech, Inc. Optical Mouse M90
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc05a Optical Mouse M90
bcdDevice 54.00
iManufacturer 1 Logitech
iProduct 2 USB Optical Mouse
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 98mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 67
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0006 1x 6 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)

Bus 002 Device 010: ID 046d:c31d Logitech, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc31d
bcdDevice 66.00
iManufacturer 1 Logitech
iProduct 2 USB Keyboard
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 59
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 3 U66.00_B0001
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 90mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 2 USB Keyboard
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 65
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 2 USB Keyboard
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 159
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 255
Device Status: 0x0000
(Bus Powered)

Bus 001 Device 011: ID 0781:5406 SanDisk Corp. Cruzer Micro U3
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0781 SanDisk Corp.
idProduct 0x5406 Cruzer Micro U3
bcdDevice 0.10
iManufacturer 1 SanDisk
iProduct 2 U3 Cruzer Micro
iSerial 3 0000186265743522
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)




--
Octavio.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/op.wg407vv26g6bxc@localhost.localdomain
 
Old 07-09-2012, 12:28 AM
Alan Stern
 
Default Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51

On Sun, 8 Jul 2012, Octavio Alvarez wrote:

> >> On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern
> >> <stern@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.LNX.4.44L0.1207082018260.16235-100000@netrider.rowland.org">http://lists.debian.org/Pine.LNX.4.44L0.1207082018260.16235-100000@netrider.rowland.org
 
Old 07-09-2012, 04:22 PM
"Octavio Alvarez"
 
Default Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51

On Sun, 08 Jul 2012 17:28:25 -0700, Alan Stern <stern@rowland.harvard.edu>
wrote:



>> 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.


Alan, take a look at this:

Bus# 2
`-Dev# 1 Vendor 0x1d6b Product 0x0001 Linux Foundation 1.1 root hub
|-Dev# 18 Vendor 0x046d Product 0xc05a Logitech, Inc. Optical Mouse M90
`-Dev# 19 Vendor 0x046d Product 0xc31d Logitech, Inc.
Bus# 1
`-Dev# 1 Vendor 0x1d6b Product 0x0002 Linux Foundation 2.0 root hub
`-Dev# 18 Vendor 0x0781 Product 0x5406 SanDisk Corp. Cruzer Micro U3

For some reason, my USB drive is now on EHCI!


What happens if you unplug only the keyboard, or only the mouse?


The only thing I can confirm for now is that with both disconnected
the system consistently suspends and that I have seen the system NOT
suspend with either one connected.

Having said that, I have also seen the system suspend, but I don't
quite trust these tests. I think I may have failed to make sure
the settings were appropriate for the test (wrong kernel or wakeup
disabled).


--
Octavio.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/op.wg6s36yq6g6bxc@localhost.localdomain
 
Old 07-09-2012, 07:05 PM
Alan Stern
 
Default Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51

On Mon, 9 Jul 2012, Octavio Alvarez wrote:

> On Sun, 08 Jul 2012 17:28:25 -0700, Alan Stern <stern@rowland.harvard.edu>
> wrote:
>
> >> >> 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.
>
> Alan, take a look at this:
>
> Bus# 2
> `-Dev# 1 Vendor 0x1d6b Product 0x0001 Linux Foundation 1.1 root hub
> |-Dev# 18 Vendor 0x046d Product 0xc05a Logitech, Inc. Optical Mouse M90
> `-Dev# 19 Vendor 0x046d Product 0xc31d Logitech, Inc.
> Bus# 1
> `-Dev# 1 Vendor 0x1d6b Product 0x0002 Linux Foundation 2.0 root hub
> `-Dev# 18 Vendor 0x0781 Product 0x5406 SanDisk Corp. Cruzer Micro U3
>
> For some reason, my USB drive is now on EHCI!

As it should be. Was there ever a time when it was definitely using
the OHCI controller? (The CCS status you got before wasn't definite
enough to count -- it showed a connected status but not an enabled
status.) That should never happen, except when ehci-hcd is unloaded.

> > What happens if you unplug only the keyboard, or only the mouse?
>
> The only thing I can confirm for now is that with both disconnected
> the system consistently suspends and that I have seen the system NOT
> suspend with either one connected.
>
> Having said that, I have also seen the system suspend, but I don't
> quite trust these tests. I think I may have failed to make sure
> the settings were appropriate for the test (wrong kernel or wakeup
> disabled).

Well, we can assume that the suspend doesn't work when either device is
plugged in.

Which suggests another test. Try unloading ehci-hcd, and plug in the
pen drive. At that point it should use the OHCI controller. Then if
you unplug the keyboard and mouse, what happens when you suspend?

My guess is that it will resume immediately.

Alan Stern




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.LNX.4.44L0.1207091459350.1954-100000@iolanthe.rowland.org">http://lists.debian.org/Pine.LNX.4.44L0.1207091459350.1954-100000@iolanthe.rowland.org
 
Old 10-05-2012, 02:56 PM
Alan Stern
 
Default Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51

On Mon, 9 Jul 2012, Octavio Alvarez wrote:

> > What happens if you unplug only the keyboard, or only the mouse?
>
> The only thing I can confirm for now is that with both disconnected
> the system consistently suspends and that I have seen the system NOT
> suspend with either one connected.
>
> Having said that, I have also seen the system suspend, but I don't
> quite trust these tests. I think I may have failed to make sure
> the settings were appropriate for the test (wrong kernel or wakeup
> disabled).

Did anything ever happen with this?

Alan Stern


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.LNX.4.44L0.1210051055520.1541-100000@iolanthe.rowland.org">http://lists.debian.org/Pine.LNX.4.44L0.1210051055520.1541-100000@iolanthe.rowland.org
 
Old 10-05-2012, 03:44 PM
Octavio Alvarez
 
Default Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51

On 10/05/2012 07:56 AM, Alan Stern wrote:

On Mon, 9 Jul 2012, Octavio Alvarez wrote:


What happens if you unplug only the keyboard, or only the mouse?


The only thing I can confirm for now is that with both disconnected
the system consistently suspends and that I have seen the system NOT
suspend with either one connected.

Having said that, I have also seen the system suspend, but I don't
quite trust these tests. I think I may have failed to make sure
the settings were appropriate for the test (wrong kernel or wakeup
disabled).


Did anything ever happen with this?



Well, there was the workaround:

echo disabled > /sys/devices/pci0000:00/0000:00:0b.0/power/wakeup

... which I applied on startup at /etc/rc.local and has worked
beautifully for me since.


Further testing started to get us nowhere. As far as conclusions
regarding hardware, we got to "the PC is doing something fishy or is
weirdly wired up". I also concluded that it wasn't actually a
"regression" because on 3.1, enabling "0:0:0b.0/power/wakeup" also made
the system autoresume. It's just that the policy changed and that's how
my system got broken, but the policy can be tweaked on /etc/rc.local.


I went on vacation and forgot after that.

However, I also started to distrust my pen drive, as it has been
randomly acting up other Linux systems. This causes it to unmount by
itself, throw journal errors, etc. Not sure if the pen drive is damaged,
or the kernel has problem, as my iPhone does similar things sometimes
and that's not damaged. In any case, conclusions drawn from the pen
drive might be incorrect now and we might have to retest.


So, theories:

a. My MCP51 is damaged.
b. The MCP51 designer or manufacturer's brain is damaged.
c. The kernel programming is wrong for MCP51.

And options:

a. Somehow "blacklist" power/wakeup for this device and call it a day.
b. Continue testing the weird stuff until we squash the sucker, which
I'm more than willing to do. We can re-test from scratch if necessary to
rebuild the whole test matrix. I may need detailed instructions for some
tests.


I would get a new pendrive just to get that out of the way. There are
some cheap Kingstons out there I can get.


Thanks.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 506F004B.80202@alvarezp.com">http://lists.debian.org/506F004B.80202@alvarezp.com
 
Old 10-05-2012, 03:45 PM
Frank Schäfer
 
Default Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51

Am 05.10.2012 18:44, schrieb Octavio Alvarez:
> On 10/05/2012 07:56 AM, Alan Stern wrote:
>> On Mon, 9 Jul 2012, Octavio Alvarez wrote:
>>
>>>> What happens if you unplug only the keyboard, or only the mouse?
>>>
>>> The only thing I can confirm for now is that with both disconnected
>>> the system consistently suspends and that I have seen the system NOT
>>> suspend with either one connected.
>>>
>>> Having said that, I have also seen the system suspend, but I don't
>>> quite trust these tests. I think I may have failed to make sure
>>> the settings were appropriate for the test (wrong kernel or wakeup
>>> disabled).
>>
>> Did anything ever happen with this?
>>
>
> Well, there was the workaround:
>
> echo disabled > /sys/devices/pci0000:00/0000:00:0b.0/power/wakeup
>
> ... which I applied on startup at /etc/rc.local and has worked
> beautifully for me since.
>
> Further testing started to get us nowhere. As far as conclusions
> regarding hardware, we got to "the PC is doing something fishy or is
> weirdly wired up". I also concluded that it wasn't actually a
> "regression" because on 3.1, enabling "0:0:0b.0/power/wakeup" also
> made the system autoresume. It's just that the policy changed and
> that's how my system got broken, but the policy can be tweaked on
> /etc/rc.local.
>
> I went on vacation and forgot after that.
>
> However, I also started to distrust my pen drive, as it has been
> randomly acting up other Linux systems. This causes it to unmount by
> itself, throw journal errors, etc. Not sure if the pen drive is
> damaged, or the kernel has problem, as my iPhone does similar things
> sometimes and that's not damaged. In any case, conclusions drawn from
> the pen drive might be incorrect now and we might have to retest.
>
> So, theories:
>
> a. My MCP51 is damaged.
> b. The MCP51 designer or manufacturer's brain is damaged.
> c. The kernel programming is wrong for MCP51.

I just want to let you know that I'm having exactly the same problem
with the Nvidia MCP61. The first linux kernel I tried with this hardware
was ~2.6.16 and it already din't work there...
I don't know much about the powermanagement stuff, but I can certainly
test patches and provide informations about the system if needed.

Regards,
Frank

>
> And options:
>
> a. Somehow "blacklist" power/wakeup for this device and call it a day.
> b. Continue testing the weird stuff until we squash the sucker, which
> I'm more than willing to do. We can re-test from scratch if necessary
> to rebuild the whole test matrix. I may need detailed instructions for
> some tests.
>
> I would get a new pendrive just to get that out of the way. There are
> some cheap Kingstons out there I can get.
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 506F009C.1040507@gmx.net">http://lists.debian.org/506F009C.1040507@gmx.net
 

Thread Tools




All times are GMT. The time now is 11:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org