Bug 24952 - MCEUSB - being in S3 no power-on via USB event.
MCEUSB - being in S3 no power-on via USB event.
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Product: Drivers
Classification: Unclassified
Component: USB
All Linux
: P1 normal
Assigned To: Greg Kroah-Hartman
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2010-12-15 21:47 UTC by warpme
Modified: 2011-02-02 20:04 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.36
Tree: Mainline
Regression: Yes


Attachments

Description warpme 2010-12-15 21:47:58 UTC
After migrating from 2.6.33.7 to 2.6.36.2 system, being in S3, can't be power-on S3 via USB event. Power button works (resumes properly from S3).
Comment 1 Rafael J. Wysocki 2010-12-15 22:37:56 UTC
I guess you need to enable your USB devices and USB controllers to wakeup
the system via their /sys/devices/.../power/wakeup sysfs attributes.
Comment 2 warpme 2010-12-16 09:16:28 UTC
Rafael,
Thx for quick replay. For sure I have enabled wakeup for given device. Sys was working OK for 2.6.33.7 with exact this config/enviroment. Is 2.6.36.2 requiring something additional ?
br
Comment 3 Rafael J. Wysocki 2011-01-16 22:47:19 UTC
I guess the problem is still there in 2.6.37?

Reassigning to USB.
Comment 4 warpme 2011-01-17 20:31:15 UTC
On 1/16/11 11:47 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=24952
>
>
> Rafael J. Wysocki<rjw@sisk.pl>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|NEW                         |NEEDINFO
>            Component|Hibernation/Suspend         |USB
>           AssignedTo|power-management_other@kern |greg@kroah.com
>                     |el-bugs.osdl.org            |
>              Product|Power Management            |Drivers
>
>
>
>
> --- Comment #3 from Rafael J. Wysocki<rjw@sisk.pl>   2011-01-16 22:47:19 ---
> I guess the problem is still there in 2.6.37?
>
> Reassigning to USB.
>
Rafael,
Thx for keeping eye on this bug.
I do tests with 2.6.36.2 and 2.6.37 (kernels recompiled on fully 
functional 2.6.33.7 based system).
For 2.6.36.x and 2.6.37 I'm able power-on via MCE USB in S3 sleep state 
but only when I do additionally:

"echo enabled > $usbpath/power/wakeup" where $usbpath is i.e 
"/sys/bus/usb/devices/2-3"

For 2.6.33.x only

"echo USBx > /proc/acpi/wakeup" is enough.

Also with 2.6.37 I have (for 1 for 5 attempts) situation where system 
immediately resumes after entering sleep state.
In such cases messages.log shows following log which IMHO is showing 
issue with USB (Device 0000:00:04.0 is OHCI controler):


Jan 16 22:21:52 (none) local0.info minimyth: [mm_sleep] Killing irexec
Jan 16 22:21:52 (none) local0.info minimyth: [mm_sleep] Killing 
SLEEP_ON_SS script
Jan 16 22:21:52 (none) local0.info minimyth: [mm_sleep] Synchronizing 
RTC clock.
Jan 16 22:21:52 (none) local0.info minimyth: [mm_sleep] Entering S3 state...
Jan 16 22:21:52 (none) user.info kernel: PM: Syncing filesystems ... done.
Jan 16 22:21:54 (none) user.warn kernel: Freezing user space processes ...
Jan 16 22:21:54 (none) daemon.notice acpid: client 7337[0:1000] has 
disconnected
Jan 16 22:21:54 (none) user.info kernel: (elapsed 0.01 seconds) done.
Jan 16 22:21:54 (none) user.warn kernel: Freezing remaining freezable 
tasks ... (elapsed 0.01 seconds) done.
Jan 16 22:21:54 (none) user.warn kernel: Suspending console(s) (use 
no_console_suspend to debug)
Jan 16 22:21:54 (none) user.notice kernel: sd 0:0:0:0: [sda] 
Synchronizing SCSI cache
Jan 16 22:21:54 (none) user.warn kernel: lirc_mceusb[2]: suspend
Jan 16 22:21:54 (none) user.info kernel: ehci_hcd 0000:00:04.1: PCI INT 
B disabled
Jan 16 22:21:54 (none) user.debug kernel: forcedeth 0000:00:0a.0: PME# 
enabled
Jan 16 22:21:54 (none) user.info kernel: forcedeth 0000:00:0a.0: wake-up 
capability enabled by ACPI
Jan 16 22:21:54 (none) user.err kernel: pci_pm_suspend(): 
hcd_pci_suspend+0x0/0x2a returns -16
Jan 16 22:21:54 (none) user.err kernel: pm_op(): 
pci_pm_suspend+0x0/0x198 returns -16
Jan 16 22:21:54 (none) user.err kernel: PM: Device 0000:00:04.0 failed 
to suspend async: error -16
Jan 16 22:21:54 (none) user.info kernel: HDA Intel 0000:00:08.0: PCI INT 
A disabled
Jan 16 22:21:54 (none) user.info kernel: HDA Intel 0000:00:08.0: power 
state changed by ACPI to D3
Jan 16 22:21:54 (none) user.notice kernel: sd 0:0:0:0: [sda] Stopping disk
Jan 16 22:21:54 (none) user.err kernel: PM: Some devices failed to suspend
Jan 16 22:21:54 (none) user.info kernel: ehci_hcd 0000:00:04.1: PCI INT 
B -> Link[LUB2] -> GSI 18 (level, low) -> IRQ 18
Jan 16 22:21:54 (none) user.debug kernel: ehci_hcd 0000:00:04.1: setting 
latency timer to 64
Jan 16 22:21:54 (none) user.info kernel: HDA Intel 0000:00:08.0: power 
state changed by ACPI to D0
Jan 16 22:21:54 (none) user.debug kernel: pci 0000:00:09.0: setting 
latency timer to 64
Jan 16 22:21:54 (none) user.info kernel: pci 0000:00:15.0: PCI INT A -> 
Link[LRP3] -> GSI 23 (level, low) -> IRQ 23
Jan 16 22:21:54 (none) user.debug kernel: pci 0000:00:15.0: setting 
latency timer to 64
Jan 16 22:21:54 (none) user.notice kernel: sd 0:0:0:0: [sda] Starting disk
Jan 16 22:21:54 (none) user.info kernel: HDA Intel 0000:00:08.0: BAR 0: 
set to [mem 0xfae78000-0xfae7bfff] (PCI address [0xfae78000-0xfae7bfff])
Jan 16 22:21:54 (none) user.info kernel: forcedeth 0000:00:0a.0: BAR 0: 
set to [mem 0xfae7d000-0xfae7dfff] (PCI address [0xfae7d000-0xfae7dfff])
Jan 16 22:21:54 (none) user.info kernel: forcedeth 0000:00:0a.0: BAR 1: 
set to [io  0xd080-0xd087] (PCI address [0xd080-0xd087])
Jan 16 22:21:54 (none) user.info kernel: HDA Intel 0000:00:08.0: power 
state changed by ACPI to D0
Jan 16 22:21:54 (none) user.info kernel: forcedeth 0000:00:0a.0: BAR 2: 
set to [mem 0xfae7e800-0xfae7e8ff] (PCI address [0xfae7e800-0xfae7e8ff])
Jan 16 22:21:54 (none) user.info kernel: forcedeth 0000:00:0a.0: BAR 3: 
set to [mem 0xfae7e400-0xfae7e40f] (PCI address [0xfae7e400-0xfae7e40f])
Jan 16 22:21:54 (none) user.debug kernel: HDA Intel 0000:00:08.0: 
restoring config space at offset 0xf (was 0x5020100, writing 0x502010a)
Jan 16 22:21:54 (none) user.debug kernel: forcedeth 0000:00:0a.0: 
restoring config space at offset 0xf (was 0x14010100, writing 0x1401010b)
Jan 16 22:21:54 (none) user.debug kernel: HDA Intel 0000:00:08.0: 
restoring config space at offset 0x1 (was 0xb00000, writing 0xb00002)
Jan 16 22:21:54 (none) user.debug kernel: forcedeth 0000:00:0a.0: 
restoring config space at offset 0x1 (was 0xb00000, writing 0xb00007)
Jan 16 22:21:54 (none) user.info kernel: HDA Intel 0000:00:08.0: power 
state changed by ACPI to D0
Jan 16 22:21:54 (none) user.info kernel: forcedeth 0000:00:0a.0: wake-up 
capability disabled by ACPI
Jan 16 22:21:54 (none) user.debug kernel: forcedeth 0000:00:0a.0: PME# 
disabled
Jan 16 22:21:54 (none) user.info kernel: HDA Intel 0000:00:08.0: power 
state changed by ACPI to D0
Jan 16 22:21:54 (none) user.info kernel: HDA Intel 0000:00:08.0: power 
state changed by ACPI to D0
Jan 16 22:21:54 (none) user.info kernel: HDA Intel 0000:00:08.0: power 
state changed by ACPI to D0
Jan 16 22:21:54 (none) user.info kernel: HDA Intel 0000:00:08.0: PCI INT 
A -> Link[LAZA] -> GSI 20 (level, low) -> IRQ 20
Jan 16 22:21:54 (none) user.debug kernel: HDA Intel 0000:00:08.0: 
setting latency timer to 64
Jan 16 22:21:54 (none) user.info kernel: eth0: no link during 
initialization.
Jan 16 22:21:54 (none) user.warn kernel: lirc_mceusb[2]: resume
Jan 16 22:21:54 (none) user.info kernel: PM: resume of devices complete 
after 898.526 msecs
Jan 16 22:21:54 (none) user.warn kernel: Restarting tasks ... done.
Jan 16 22:21:54 (none) local0.info minimyth: [mm_sleep] Returning from 
S3 state...
Jan 16 22:21:54 (none) local0.info minimyth: [mm_sleep] Restarting 
SLEEP_ON_SS script
Jan 16 22:21:54 (none) local0.info minimyth: [mm_sleep] Restarting irexec


br
Comment 5 warpme 2011-01-17 21:37:46 UTC
Well, it seems like 2.6.36.3 has the same issue with random immediate resume after entering sleep state. Also logs looks similar.
Comment 6 Rafael J. Wysocki 2011-01-17 22:33:09 UTC
> For 2.6.36.x and 2.6.37 I'm able power-on via MCE USB in S3 sleep state 
> but only when I do additionally:
>
> "echo enabled > $usbpath/power/wakeup" where $usbpath is i.e 
> "/sys/bus/usb/devices/2-3"
>
> For 2.6.33.x only
>
> "echo USBx > /proc/acpi/wakeup" is enough.

We're moving away from /proc/acpi/wakeup and it's going the be removed at
one point, so please use the sysfs interface.  Also, it generally is
required to explicitly enable USB wakeup, because there are many devices
that don't work correctly in that respect and we simply can't enable it
by default for every device.

Please attach the output of lspci from your system.
Comment 7 warpme 2011-01-18 16:38:09 UTC
Pls find output of lspci:

root@FE-Test:~ # lspci
00:00.0 Host bridge: nVidia Corporation MCP79 Host Bridge (rev b1)
00:00.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.0 ISA bridge: nVidia Corporation MCP79 LPC Bridge (rev b2)
00:03.1 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.2 SMBus: nVidia Corporation MCP79 SMBus (rev b1)
00:03.3 RAM memory: nVidia Corporation MCP79 Memory Controller (rev b1)
00:03.5 Co-processor: nVidia Corporation MCP79 Co-processor (rev b1)
00:04.0 USB Controller: nVidia Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:04.1 USB Controller: nVidia Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio (rev b1)
00:09.0 PCI bridge: nVidia Corporation MCP79 PCI Bridge (rev b1)
00:0a.0 Ethernet controller: nVidia Corporation MCP79 Ethernet (rev b1)
00:0b.0 IDE interface: nVidia Corporation MCP79 SATA Controller (rev b1)
00:10.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
00:15.0 PCI bridge: nVidia Corporation MCP79 PCI Express Bridge (rev b1)
01:00.0 VGA compatible controller: nVidia Corporation ION VGA (rev b1)
root@FE-Test:~ #
Comment 8 warpme 2011-01-18 19:48:17 UTC
BTW: on 2.6.36.3 issue with immediate resume after sleep is on every second sleep. For 2.6.37 can't say as I rebuild test environment to 2.6.36.3....
Comment 9 warpme 2011-01-31 16:15:36 UTC
Hi,

Following patch resolves issue for me. (based on excellent support of Paul Bender, minimyth maintainer) 

diff -Naur linux-2.6.37-old/drivers/usb/core/hcd.c linux-2.6.37-new/drivers/usb/core/hcd.c
--- linux-2.6.37-old/drivers/usb/core/hcd.c	2011-01-04 16:50:19.000000000 -0800
+++ linux-2.6.37-new/drivers/usb/core/hcd.c	2011-01-26 10:45:48.000000000 -0800
@@ -1993,6 +1993,8 @@
 
 	usb_lock_device(udev);
 	usb_remote_wakeup(udev);
+	if (hcd->state == HC_STATE_RUNNING)
+		clear_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags);
 	usb_unlock_device(udev);
 }
Comment 10 Rafael J. Wysocki 2011-01-31 18:00:14 UTC
OK

Any chance to submit the patch upstream with a proper changelog and sign-off?
Comment 11 Alan Stern 2011-01-31 19:41:57 UTC
Paul Bender submitted his patch on the linux-usb mailing list.  After some discussion, I provided him with a different patch to test:

   http://marc.info/?l=linux-usb&m=129642365501014&w=2

He says it fixes his problem.  If you find that it fixes your problem too, I will submit it for inclusion in the stable kernels.
Comment 12 warpme 2011-02-02 17:46:18 UTC
Alan,

I tested patch on 3 machines - so far no any issues. I think issue is resolved !
Thx
Comment 13 Alan Stern 2011-02-02 18:56:47 UTC
Okay, I will submit the patch.  It should appear in 2.6.38, as well as in upcoming 2.6.36 and 2.6.37 stable kernels.

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