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: | USB | Assignee: | 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 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| 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
Created attachment 26535 [details]
dmidecode output
The output of dmidecode.
(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. > 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 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 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 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
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.
(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 Hi, Alan, what's the status of this bug? 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. Submitted to Fedora kernel maintenance : https://bugzilla.redhat.com/show_bug.cgi?id=613401 proposed patch is a USB patch, not an ACPI patch, so booting this bug report to the USB sub-system. The fix should now be present in the 2.6.33.7 kernel. Scott, can you verify that it works okay? 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! Okay, great! I'm going to close out this bug report. If you want, you can open another one for the video issue. |