Bug 16043 - Resume w/USB remote working in 2.6.33.2, no longer in 2.6.33.10
Summary: Resume w/USB remote working in 2.6.33.2, no longer in 2.6.33.10
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Alan Stern
URL:
Keywords:
Depends on:
Blocks: 7216 56331
  Show dependency tree
 
Reported: 2010-05-25 03:51 UTC by Scott Sturdivant
Modified: 2013-04-09 06:23 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.33.10
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmidecode output (11.14 KB, text/plain)
2010-05-25 03:56 UTC, Scott Sturdivant
Details
Allow remote wakeup even if drivers don't ask for it (1.16 KB, patch)
2010-06-07 15:07 UTC, Alan Stern
Details | Diff

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.

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