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.
Created attachment 24822 [details] 2.6.31 dmesg log after boot
Created attachment 24823 [details] 2.6.31 dmesg log after resume from suspend to ram
Created attachment 24824 [details] 2.6.31 lspci -v output
Created attachment 24825 [details] 2.6.31 lsusb -v output
Created attachment 24826 [details] 2.6.33-rc6 dmesg log after boot
Created attachment 24827 [details] 2.6.33-rc6 dmesg log after suspend failed
Created attachment 24828 [details] 2.6.33-rc6 dmesg log after unload ehci_hcd module and suspend
Created attachment 24829 [details] 2.6.33-rc6 kernel config
Created attachment 24830 [details] 2.6.33-rc6 lspci -v output
Created attachment 24831 [details] 2.6.33-rc6 lsusb -v output
(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.
Created attachment 24876 [details] 2.6.33-rc6 dmesg log after suspend failed (CONFIG_USB_DEBUG=y)
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
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
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
> > 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
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
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...
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
Why did this problem suddenly emerge? Has the suspend / resume path noticeably changed?