Bug 15189 - Suspend failed with ehci_hcd module
Suspend failed with ehci_hcd module
Status: CLOSED INVALID
Product: Drivers
Classification: Unclassified
Component: USB
All Linux
: P1 low
Assigned To: Greg Kroah-Hartman
:
Depends on:
Blocks: 7216 14230
  Show dependency treegraph
 
Reported: 2010-01-31 15:00 UTC by Lukáš Karas
Modified: 2010-02-07 12:14 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.33-rc6
Tree: Mainline
Regression: Yes


Attachments
2.6.31 dmesg log after boot (44.72 KB, text/plain)
2010-01-31 15:02 UTC, Lukáš Karas
Details
2.6.31 dmesg log after resume from suspend to ram (11.33 KB, text/plain)
2010-01-31 15:07 UTC, Lukáš Karas
Details
2.6.31 lspci -v output (6.94 KB, text/plain)
2010-01-31 15:17 UTC, Lukáš Karas
Details
2.6.31 lsusb -v output (14.18 KB, text/plain)
2010-01-31 15:17 UTC, Lukáš Karas
Details
2.6.33-rc6 dmesg log after boot (46.88 KB, text/plain)
2010-01-31 15:18 UTC, Lukáš Karas
Details
2.6.33-rc6 dmesg log after suspend failed (1.04 KB, text/plain)
2010-01-31 15:19 UTC, Lukáš Karas
Details
2.6.33-rc6 dmesg log after unload ehci_hcd module and suspend (10.62 KB, text/plain)
2010-01-31 15:20 UTC, Lukáš Karas
Details
2.6.33-rc6 kernel config (95.26 KB, text/plain)
2010-01-31 15:21 UTC, Lukáš Karas
Details
2.6.33-rc6 lspci -v output (7.27 KB, text/plain)
2010-01-31 15:21 UTC, Lukáš Karas
Details
2.6.33-rc6 lsusb -v output (14.17 KB, text/plain)
2010-01-31 15:22 UTC, Lukáš Karas
Details
2.6.33-rc6 dmesg log after suspend failed (CONFIG_USB_DEBUG=y) (65.82 KB, text/plain)
2010-02-02 16:08 UTC, Lukáš Karas
Details

Description Lukáš Karas 2010-01-31 15:00:38 UTC
Hi all. 

New kernel (2.6.33, tested on rc5 and rc6 version) failed suspend to ram.

echo mem > /sys/power/state

kernel log:
[ 4108.481008] pm_op(): usb_dev_suspend+0x0/0x10 [usbcore] returns -16
[ 4108.481016] PM: Device usb3 failed to suspend: error -16
[ 4108.481021] PM: Some devices failed to suspend

If I unload module ehci_hcd, suspend works fine. Suspend to ram works with  kernel 2.6.31 on this hardware. Logs coming soon...

Btw, sorry for my english.
Comment 1 Lukáš Karas 2010-01-31 15:02:03 UTC
Created attachment 24822 [details]
2.6.31 dmesg log after boot
Comment 2 Lukáš Karas 2010-01-31 15:07:42 UTC
Created attachment 24823 [details]
2.6.31 dmesg log after resume from suspend to ram
Comment 3 Lukáš Karas 2010-01-31 15:17:23 UTC
Created attachment 24824 [details]
2.6.31 lspci -v output
Comment 4 Lukáš Karas 2010-01-31 15:17:47 UTC
Created attachment 24825 [details]
2.6.31 lsusb -v output
Comment 5 Lukáš Karas 2010-01-31 15:18:49 UTC
Created attachment 24826 [details]
2.6.33-rc6 dmesg log after boot
Comment 6 Lukáš Karas 2010-01-31 15:19:38 UTC
Created attachment 24827 [details]
2.6.33-rc6 dmesg log after suspend failed
Comment 7 Lukáš Karas 2010-01-31 15:20:23 UTC
Created attachment 24828 [details]
2.6.33-rc6 dmesg log after unload ehci_hcd module and suspend
Comment 8 Lukáš Karas 2010-01-31 15:21:07 UTC
Created attachment 24829 [details]
2.6.33-rc6 kernel config
Comment 9 Lukáš Karas 2010-01-31 15:21:35 UTC
Created attachment 24830 [details]
2.6.33-rc6 lspci -v output
Comment 10 Lukáš Karas 2010-01-31 15:22:06 UTC
Created attachment 24831 [details]
2.6.33-rc6 lsusb -v output
Comment 11 Andrew Morton 2010-02-01 21:46:20 UTC
(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Sun, 31 Jan 2010 15:00:39 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=15189
> 
>            Summary: Suspend failed with ehci_hcd module
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 2.6.33-rc6
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: low
>           Priority: P1
>          Component: USB
>         AssignedTo: greg@kroah.com
>         ReportedBy: lukas.karas@centrum.cz
>         Regression: Yes
> 
> 
> Hi all. 
> 
> New kernel (2.6.33, tested on rc5 and rc6 version) failed suspend to ram.
> 
> echo mem > /sys/power/state
> 
> kernel log:
> [ 4108.481008] pm_op(): usb_dev_suspend+0x0/0x10 [usbcore] returns -16
> [ 4108.481016] PM: Device usb3 failed to suspend: error -16
> [ 4108.481021] PM: Some devices failed to suspend
> 
> If I unload module ehci_hcd, suspend works fine. Suspend to ram works with 
> kernel 2.6.31 on this hardware. Logs coming soon...
> 
> Btw, sorry for my english.
> 

A 2.6.31 -> 2.6.33-rc regression.
Comment 12 Lukáš Karas 2010-02-02 16:08:30 UTC
Created attachment 24876 [details]
2.6.33-rc6 dmesg log after suspend failed (CONFIG_USB_DEBUG=y)
Comment 13 Lukáš Karas 2010-02-02 16:49:34 UTC
Hi All, here is dmesg log with enabled CONFIG_USB_DEBUG option.

http://bugzilla.kernel.org/attachment.cgi?id=24876


Dne Mon 1. of February 2010 22:42:35 Alan Stern napsal(a):
> On Mon, 1 Feb 2010, Andrew Morton wrote:
> > > http://bugzilla.kernel.org/show_bug.cgi?id=15189
> > > 
> > >            Summary: Suspend failed with ehci_hcd module
> > > 
> > > Hi all.
> > > 
> > > New kernel (2.6.33, tested on rc5 and rc6 version) failed suspend to
> > > ram.
> > > 
> > > echo mem > /sys/power/state
> > > 
> > > kernel log:
> > > [ 4108.481008] pm_op(): usb_dev_suspend+0x0/0x10 [usbcore] returns -16
> > > [ 4108.481016] PM: Device usb3 failed to suspend: error -16
> > > [ 4108.481021] PM: Some devices failed to suspend
> > > 
> > > If I unload module ehci_hcd, suspend works fine. Suspend to ram works
> > > with kernel 2.6.31 on this hardware. Logs coming soon...
> 
> Please enable CONFIG_USB_DEBUG and attach another dmesg log to the bug
> report showing what happens during a failed suspend.  Also post a
> reply to this message when the new log is ready, so we will know.
> 
> Alan Stern
Comment 14 Alan Stern 2010-02-02 18:16:06 UTC
On Tue, 2 Feb 2010, [utf-8] Lukáš Karas wrote:

> Hi All, here is dmesg log with enabled CONFIG_USB_DEBUG option.
> 
> http://bugzilla.kernel.org/attachment.cgi?id=24876

And here in the log is the explanation:

> [  136.971239] usb 3-4: usb suspend
> [  136.977281] ehci_hcd 0000:00:13.2: port 4 remote wakeup
> [  136.987120] hub 3-0:1.0: hub_suspend
> [  136.987130] usb usb3: bus suspend
> [  136.987135] ehci_hcd 0000:00:13.2: suspend root hub
> [  136.987141] ehci_hcd 0000:00:13.2: suspend failed because port 4 is resuming

Earlier on the log states that device 3-4 is a "USB2.0 Camera";  
presumably you know what it really is.  Evidently that device is
telling the computer it wants to wake up again as soon as the computer
puts it to sleep.

If you know that this is bogus, you can prevent the camera from sending 
wakeup requests as follows:

	echo disabled >/sys/bus/usb/devices/3-4/power/wakeup

Alan Stern
Comment 15 Alan Stern 2010-02-02 19:39:16 UTC
On Mon, 1 Feb 2010, Andrew Morton wrote:

> > http://bugzilla.kernel.org/show_bug.cgi?id=15189
> > 
> >            Summary: Suspend failed with ehci_hcd module

> > Hi all. 
> > 
> > New kernel (2.6.33, tested on rc5 and rc6 version) failed suspend to ram.
> > 
> > echo mem > /sys/power/state
> > 
> > kernel log:
> > [ 4108.481008] pm_op(): usb_dev_suspend+0x0/0x10 [usbcore] returns -16
> > [ 4108.481016] PM: Device usb3 failed to suspend: error -16
> > [ 4108.481021] PM: Some devices failed to suspend
> > 
> > If I unload module ehci_hcd, suspend works fine. Suspend to ram works with 
> > kernel 2.6.31 on this hardware. Logs coming soon...

Please enable CONFIG_USB_DEBUG and attach another dmesg log to the bug
report showing what happens during a failed suspend.  Also post a
reply to this message when the new log is ready, so we will know.

Alan Stern
Comment 16 Lukáš Karas 2010-02-02 21:49:53 UTC
> 
> Earlier on the log states that device 3-4 is a "USB2.0 Camera";
> presumably you know what it really is.  Evidently that device is
> telling the computer it wants to wake up again as soon as the computer
> puts it to sleep.
> 
> If you know that this is bogus, you can prevent the camera from sending
> wakeup requests as follows:
> 
> 	echo disabled >/sys/bus/usb/devices/3-4/power/wakeup
> 
> Alan Stern


Thank you, it works! So, I quess that it isn't a kernel bug... Sorry for my 
unfamiliarity. 


I added simple udev rule
SYSFS{idVendor}=="0402", SYSFS{idProduct}=="5602", 
ATTR{power/wakeup}="disabled"

now is device setup correctly in boot time...

Lukas
Comment 17 Alan Stern 2010-02-03 15:08:05 UTC
On Tue, 2 Feb 2010, [utf-8] Lukáš Karas wrote:

> Thank you, it works! So, I quess that it isn't a kernel bug... Sorry for my 
> unfamiliarity. 
> 
> 
> I added simple udev rule
> SYSFS{idVendor}=="0402", SYSFS{idProduct}=="5602", 
> ATTR{power/wakeup}="disabled"
> 
> now is device setup correctly in boot time...

Okay, so this bug report can be closed out.  You should mark it as
REJECTED.

By the way, what is that "USB2.0 Camera"?  It'll be good to know, since 
other people may be affected by the same problem.

Alan Stern
Comment 18 Lukáš Karas 2010-02-03 15:55:25 UTC
This is a
0402:5602 ALi Corp. Video Camera Controller, 
build in camera instaled in notebooks like Acer (Aspire 5100 series), Asus, MSI... It is controled by module gspca_m5602. 

I will write some info about it to udev mail list...
Comment 19 Lukáš Karas 2010-02-03 16:50:59 UTC
This is a
0402:5602 ALi Corp. Video Camera Controller, 
build in camera instaled in notebooks like Acer (Aspire 5100 series), Asus, 
MSI... It is controled by module gspca_m5602. 

I will write some info about it to udev mail list...

Dne Wed 3. of February 2010 16:07:24 Alan Stern napsal(a):
> On Tue, 2 Feb 2010, [utf-8] Lukáš Karas wrote:
> > Thank you, it works! So, I quess that it isn't a kernel bug... Sorry for
> > my unfamiliarity.
> > 
> > 
> > I added simple udev rule
> > SYSFS{idVendor}=="0402", SYSFS{idProduct}=="5602",
> > ATTR{power/wakeup}="disabled"
> > 
> > now is device setup correctly in boot time...
> 
> Okay, so this bug report can be closed out.  You should mark it as
> REJECTED.
> 
> By the way, what is that "USB2.0 Camera"?  It'll be good to know, since
> other people may be affected by the same problem.
> 
> Alan Stern
Comment 20 Erik Andr 2010-02-07 12:14:45 UTC
Why did this problem suddenly emerge?
Has the suspend / resume path noticeably changed?

Note You need to log in before you can comment on or make changes to this bug.