Bug 16043

Summary: Resume w/USB remote working in 2.6.33.2, no longer in 2.6.33.10
Product: Drivers Reporter: Scott Sturdivant (scott)
Component: USBAssignee: Alan Stern (stern)
Status: CLOSED CODE_FIX    
Severity: normal CC: Didier.Moens, lenb, rjw, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.33.10 Tree: Mainline
Regression: Yes
Bug Depends on:    
Bug Blocks: 7216, 56331    
Attachments: dmidecode output
Allow remote wakeup even if drivers don't ask for it

Description Scott Sturdivant 2010-05-25 03:51:17 UTC
Using the latest Arch Linux kernel (2.6.33.10-1), the contents of /proc/acpi/wakeup are:

[scott@blargh-htpc ~]$ cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
HUB0      S5     disabled  pci:0000:00:09.0
XVR0      S5     disabled
XVR1      S5     disabled
XVR2      S5     disabled
XVR3      S5     disabled
XVR4      S5     disabled  pci:0000:00:16.0
XVR5      S5     disabled
XVR6      S5     disabled
UAR1      S5     disabled  pnp:00:08
USB0      S4     enabled   pci:0000:00:04.0
USB1      S4     disabled  pci:0000:00:06.0
USBB      S3     disabled  pci:0000:00:06.1
USB2      S3     disabled  pci:0000:00:04.1
AZAD      S5     disabled  pci:0000:00:08.0
MMAC      S5     disabled  pci:0000:00:0a.0

[scott@blargh-htpc pkg]$ uname -a
Linux blargh-htpc 2.6.33-ARCH #1 SMP PREEMPT Thu May 13 11:32:37 CEST 2010 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linu
x

The machine will suspend to RAM correctly, but will no longer be resumed by a USB remote power-on event.  Instead, the power button on the machine must be pressed.  It then resumes correctly.

This behavior was not present in the previous kernel I was running: 2.6.33.2-1.  In that case, the machine powered back on correctly when the USB remote's power button was pressed.  There was an intermediate kernel release (2.6.33.4-1) that I have not tried, but certainly can do so if that might help determine where the regression was introduced.

Additionally if there's more information I can provide about the system and my setup, please let me know what is required.
Comment 1 Scott Sturdivant 2010-05-25 03:56:54 UTC
Created attachment 26535 [details]
dmidecode output

The output of dmidecode.
Comment 2 Andrew Morton 2010-05-27 20:02:11 UTC
(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Tue, 25 May 2010 03:51:20 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=16043
> 
>            Summary: Resume w/USB remote working in 2.6.33.2, no longer in
>                     2.6.33.10

This is a regression within -stable, presumably also in 2.6.34.

>            Product: ACPI
>            Version: 2.5
>     Kernel Version: 2.6.33.10
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Power-Sleep-Wake
>         AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org
>         ReportedBy: scott@binrock.net
>         Regression: Yes
> 
> 
> Using the latest Arch Linux kernel (2.6.33.10-1), the contents of
> /proc/acpi/wakeup are:
> 
> [scott@blargh-htpc ~]$ cat /proc/acpi/wakeup
> Device  S-state   Status   Sysfs node
> HUB0      S5     disabled  pci:0000:00:09.0
> XVR0      S5     disabled
> XVR1      S5     disabled
> XVR2      S5     disabled
> XVR3      S5     disabled
> XVR4      S5     disabled  pci:0000:00:16.0
> XVR5      S5     disabled
> XVR6      S5     disabled
> UAR1      S5     disabled  pnp:00:08
> USB0      S4     enabled   pci:0000:00:04.0
> USB1      S4     disabled  pci:0000:00:06.0
> USBB      S3     disabled  pci:0000:00:06.1
> USB2      S3     disabled  pci:0000:00:04.1
> AZAD      S5     disabled  pci:0000:00:08.0
> MMAC      S5     disabled  pci:0000:00:0a.0
> 
> [scott@blargh-htpc pkg]$ uname -a
> Linux blargh-htpc 2.6.33-ARCH #1 SMP PREEMPT Thu May 13 11:32:37 CEST 2010
> x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linu
> x
> 
> The machine will suspend to RAM correctly, but will no longer be resumed by a
> USB remote power-on event.  Instead, the power button on the machine must be
> pressed.  It then resumes correctly.
> 
> This behavior was not present in the previous kernel I was running:
> 2.6.33.2-1.
>  In that case, the machine powered back on correctly when the USB remote's
> power button was pressed.  There was an intermediate kernel release
> (2.6.33.4-1) that I have not tried, but certainly can do so if that might
> help
> determine where the regression was introduced.
> 
> Additionally if there's more information I can provide about the system and
> my
> setup, please let me know what is required.
>
Comment 3 Alan Stern 2010-05-27 22:02:19 UTC
On Thu, 27 May 2010, Andrew Morton wrote:

> > https://bugzilla.kernel.org/show_bug.cgi?id=16043
> > 
> >            Summary: Resume w/USB remote working in 2.6.33.2, no longer in
> >                     2.6.33.10

> > Using the latest Arch Linux kernel (2.6.33.10-1), the contents of
> > /proc/acpi/wakeup are:

/proc/acpi/wakeup doesn't matter.  What matters are the power/wakeup 
files under /sys.

> > The machine will suspend to RAM correctly, but will no longer be resumed by
> a
> > USB remote power-on event.  Instead, the power button on the machine must
> be
> > pressed.  It then resumes correctly.

By default, wakeup is disabled for USB host controllers.  This is so 
that people don't cause their suspended laptops to wake up by 
unplugging a USB mouse, for example.

If you want to enable wakeup, you have to do it manually or from a 
boot-time script like /etc/rc.d/rc.local.  For example, you might need 
to do:

	echo enabled >/sys/bus/pci/devices/0000:00:04.0/power/wakeup

The system has been this way a long time, but up until just now it
didn't work correctly.

Alan Stern
Comment 4 Scott Sturdivant 2010-05-29 04:13:05 UTC
On Thu, 27 May 2010, Alan Stern wrote:

> On Thu, 27 May 2010, Andrew Morton wrote:
>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=16043
>>>
>>>            Summary: Resume w/USB remote working in 2.6.33.2, no longer in
>>>                     2.6.33.10

First I need to back track and fix an error -- it's version 2.6.33.4 that 
this no longer works in, not 2.6.33.10 as I had indicated.

> /proc/acpi/wakeup doesn't matter.  What matters are the power/wakeup
> files under /sys.

Ok, all manipulation of /proc/acpi/wakeup is no off, so all devices read 
as "disabled".

> If you want to enable wakeup, you have to do it manually or from a
> boot-time script like /etc/rc.d/rc.local.  For example, you might need
> to do:
>
>       echo enabled >/sys/bus/pci/devices/0000:00:04.0/power/wakeup
>
> The system has been this way a long time, but up until just now it
> didn't work correctly.

In my case, "USB1" was the partical device that was waking up the system. 
According to /proc/acpi/wakeup, this is what I see:

     # grep USB1 /proc/acpi/wakeup
     USB1      S4     disabled  pci:0000:00:06.0

Now, I perform the following:

     # cat /sys/bus/pci/devices/0000\:00\:06.0/power/wakeup
        disabled
     # echo enabled > /sys/bus/pci/devices/0000\:00\:06.0/power/wakeup
     # cat /sys/bus/pci/devices/0000\:00\:06.0/power/wakeup
        enabled

Sadly it still will not resume.

Thanks for the tip, in the meantime I will go back to the 2.6.33-2 kernel 
and try modifying the /sys.../power/wakeup file in addition to / instead 
of the /proc/acpi/wakeup file.

Scott
Comment 5 Alan Stern 2010-05-29 15:29:37 UTC
On Sat, 29 May 2010, Scott Sturdivant wrote:

> >>> https://bugzilla.kernel.org/show_bug.cgi?id=16043
> >>>
> >>>            Summary: Resume w/USB remote working in 2.6.33.2, no longer in
> >>>                     2.6.33.10
> 
> First I need to back track and fix an error -- it's version 2.6.33.4 that 
> this no longer works in, not 2.6.33.10 as I had indicated.

I figured as much, since 2.6.33.5 was only released this past week.

> In my case, "USB1" was the partical device that was waking up the system. 
> According to /proc/acpi/wakeup, this is what I see:
> 
>      # grep USB1 /proc/acpi/wakeup
>      USB1      S4     disabled  pci:0000:00:06.0
> 
> Now, I perform the following:
> 
>      # cat /sys/bus/pci/devices/0000\:00\:06.0/power/wakeup
>         disabled
>      # echo enabled > /sys/bus/pci/devices/0000\:00\:06.0/power/wakeup
>      # cat /sys/bus/pci/devices/0000\:00\:06.0/power/wakeup
>         enabled
> 
> Sadly it still will not resume.
> 
> Thanks for the tip, in the meantime I will go back to the 2.6.33-2 kernel 
> and try modifying the /sys.../power/wakeup file in addition to / instead 
> of the /proc/acpi/wakeup file.

There's one more thing to check: The /sys/.../power/wakeup file for 
your USB device.  A recent change caused remote wakeup to be disabled 
by default for USB devices; that could explain the change in behavior.  
You would need to enable it explicitly, just like for the controller.

Alan Stern
Comment 6 Alan Stern 2010-06-04 21:01:45 UTC
On Sat, 29 May 2010, Scott Sturdivant wrote:

> Thanks for the tip, in the meantime I will go back to the 2.6.33-2 kernel 
> and try modifying the /sys.../power/wakeup file in addition to / instead 
> of the /proc/acpi/wakeup file.

Has you made any progress on this?

And by the way, what is your USB wakeup device?  Is there a driver for
it in the Linux kernel?

Alan Stern
Comment 7 Alan Stern 2010-06-07 15:07:55 UTC
Created attachment 26684 [details]
Allow remote wakeup even if drivers don't ask for it

You probably will need to apply this patch as well.  It undoes one of the changes made by the recent -stable update.
Comment 8 Scott Sturdivant 2010-06-08 01:18:33 UTC
(In reply to comment #6)
> On Sat, 29 May 2010, Scott Sturdivant wrote:
> 
> > Thanks for the tip, in the meantime I will go back to the 2.6.33-2 kernel 
> > and try modifying the /sys.../power/wakeup file in addition to / instead 
> > of the /proc/acpi/wakeup file.
> 
> Has you made any progress on this?
> 
> And by the way, what is your USB wakeup device?  Is there a driver for
> it in the Linux kernel?
> 
> Alan Stern

On a 2.6.33-4 kernel, patch not applied, here are the findings.

#lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 1784:0008 TopSeed Technology Corp. 
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

#dmesg:
lirc_mceusb[2]: Topseed Technology Corp. eHome Infrared Transceiver on usb4:2
usbcore: registered new interface driver lirc_mceusb

#modinfo lirc_mceusb:
filename:       /lib/modules/2.6.33-ARCH/kernel/drivers/misc/lirc_mceusb.ko

#ls /sys/bus/usb/devices:
1-0:1.0  2-0:1.0  3-0:1.0  4-0:1.0  4-1  4-1:1.0  usb1  usb2  usb3  usb4

Not sure which is the correct one (it's USB1 under /proc/acpi/wakeup, but those are 0 indexed and only go to USB2), but all /sys/bus/usb/devices/usb[1-4]/power/wakeup had 'enabled' set by default.

Now also making sure /proc/acpi/wakeup shows USB1 (and all other USB) is disabled:

# cat /proc/acpi/wakeup | grep USB
USB0      S4     disabled  pci:0000:00:04.0
USB1      S4     disabled  pci:0000:00:06.0
USBB      S3     disabled  pci:0000:00:06.1
USB2      S3     disabled  pci:0000:00:04.1

Finally, making sure the pci 6.0 is enabled:
# cat /sys/bus/pci/devices/0000\:00\:06.0/power/wakeup
enabled

Status of resume from suspend with USB device:  FAIL.

For what it's worth, the USB IR receiver has a light that appears when it receives a signal.  In this non-working case, no light is present, so my assumption is that the usb port is not powered.

Please let me know if my /sys/bus/usb/devices/usb[1-4]/power/wakeup was the wrong location.

In the meantime I will see what it takes to apply the patch and try it.  I presume you want me to try kernel.org's stable?  Is there a particular release (i.e. stick with 2.6.33.4?)

Thanks,

Scott
Comment 9 Zhang Rui 2010-06-24 08:27:08 UTC
Hi, Alan,
what's the status of this bug?
Comment 10 Didier.Moens@dmbr.UGent.be 2010-07-11 10:41:36 UTC
Running Fedora13 x86_64.

The patch from comment#7 applies cleanly to the latest stable kernel release (2.6.33.6-147.fc13.x86_64), following the Fedora kernel recompilation guidelines (http://fedoraproject.org/wiki/Docs/CustomKernel).

The resulting patched 2.6.33.6 kernel restores the previously lost functionality (confirmed with kernel module 'lirc_mceusb') ; thanks to all involved.
Comment 11 Didier.Moens@dmbr.UGent.be 2010-07-11 12:11:57 UTC
Submitted to Fedora kernel maintenance :
https://bugzilla.redhat.com/show_bug.cgi?id=613401
Comment 12 Len Brown 2010-07-13 02:04:25 UTC
proposed patch is a USB patch, not an ACPI patch, 
so booting this bug report to the USB sub-system.
Comment 13 Alan Stern 2010-08-02 19:32:47 UTC
The fix should now be present in the 2.6.33.7 kernel.  Scott, can you verify that it works okay?
Comment 14 Scott Sturdivant 2010-08-06 03:29:12 UTC
Yes, the computer resumes with a USB remote after downloading and installing the 2.6.33.7 kernel.  It doesn't resume 100% properly (no video now) but that's a different matter.  At least the issue of it not powering up at all is now gone!

Thank you everyone!
Comment 15 Alan Stern 2010-08-07 02:49:44 UTC
Okay, great!  I'm going to close out this bug report.  If you want, you can open another one for the video issue.