Bug 42721
| Summary: | no poweroff but reboot when hibernate with uhci-hcd devices connected to Asus A8V-E SE onboard USB pins , since 3.2 (rc...) | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | jospezial |
| Component: | Power-Sleep-Wake | Assignee: | Lan Tianyu (tianyu.lan) |
| Status: | CLOSED DUPLICATE | ||
| Severity: | normal | CC: | lenb, orion, rui.zhang, stern, tianyu.lan |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.2 - 3.5 - ... | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
config-3.2.2
config-3.1.9 output of dmesg before hibernating Kernel 3.1.9 output of dmesg after hibernating/resume Kernel 3.1.9 output of dmesg before hibernating Kernel 3.2.2 output of dmesg after hibernating/resume Kernel 3.2.2 output of dmesg after hibernating/resume Kernel 3.1.9 config-3.1.9 3.3.0-rc2_lspci-v.txt 3.3.0-rc2_lsusb-v.txt config-3.3.0-rc2 revert use this patch! output of acpidump with kernel 3.5-rc3 |
||
|
Description
jospezial
2012-02-03 16:55:01 UTC
Created attachment 72255 [details]
config-3.2.2
Created attachment 72256 [details]
config-3.1.9
This is where all is fine
Created attachment 72257 [details]
output of dmesg before hibernating Kernel 3.1.9
Created attachment 72258 [details]
output of dmesg after hibernating/resume Kernel 3.1.9
Created attachment 72259 [details]
output of dmesg before hibernating Kernel 3.2.2
Created attachment 72260 [details]
output of dmesg after hibernating/resume Kernel 3.2.2
Created attachment 72261 [details]
output of dmesg after hibernating/resume Kernel 3.1.9
right mime type
Created attachment 72262 [details]
config-3.1.9
right mime type
Found out, how te edit the Attachments and mark the other as obsolete but can't delete them. Please boot the system with ACPI disabled to check whether the problem is caused by ACPI. (Add the kernel parameter "acpi=off"). as 3.1.9 worked and 3.2.2 fails, marking as a regression. Would be interesting to know if the different settings in /sys/power/disk behave differently. eg. # echo shutdown > /sys/power/disk Please compare /proc/acpi/wakeup for the working vs failure kernels in case this is a USB wakeup issue, please try changing the "on" vs "auto" here: /sys/bus/pci/drivers/*_hcd/0*/power/control Booting with ACPI=off does not work on all my kernels because it loop with errors from libata with my sata-drives. (invalid chs sector 0) --------------------------------------------------- Tests: Kernel 3.3.0-rc2: output from /proc/acpi/wakeup: Device S-state Status Sysfs node PCI0 S5 *disabled no-bus:pci0000:00 USB0 S4 *disabled USB1 S4 *disabled USB2 S4 *disabled USB3 S4 *enabled pci:0000:00:10.0 USB4 S4 *enabled pci:0000:00:10.1 USB5 S4 *enabled pci:0000:00:10.2 USB6 S4 *enabled pci:0000:00:10.3 AC97 S5 *disabled pci:0000:00:11.5 PEXG S5 *disabled pci:0000:00:02.0 PEX0 S5 *disabled pci:0000:00:03.0 PEX1 S5 *disabled pci:0000:00:03.1 PEX2 S5 *disabled pci:0000:00:03.2 PEX3 S5 *disabled pci:0000:00:03.3 UAR1 S5 *disabled pnp:00:08 jlgentoo joerg # cat /sys/power/disk [platform] shutdown reboot jlgentoo joerg # echo shutdown > /sys/power/disk jlgentoo joerg # cat /sys/power/disk platform [shutdown] reboot -->It powers off on hibernate as wanted. Is this a solution? would it help to throw away all the platform stuff of my config? Do I need the platform stuff? "in case this is a USB wakeup issue,..." with standard setting ([platform] shutdown reboot) in /sys/power/disk: lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 002: ID 046d:c012 Logitech, Inc. Mouseman Dual Optical jlgentoo ~ # cat /sys/bus/pci/drivers/*_hcd/0*/power/control on on on on on jlgentoo ~ # echo auto >/sys/bus/pci/drivers/ehci_hcd/0000\:00\:10.4/power/control jlgentoo ~ # echo auto >/sys/bus/pci/drivers/uhci_hcd/0000\:00\:10. 0000:00:10.0/ 0000:00:10.1/ 0000:00:10.2/ 0000:00:10.3/ jlgentoo ~ # echo auto >/sys/bus/pci/drivers/uhci_hcd/0000\:00\:10.0/power/control jlgentoo ~ # echo auto >/sys/bus/pci/drivers/uhci_hcd/0000\:00\:10.1/power/control jlgentoo ~ # echo auto >/sys/bus/pci/drivers/uhci_hcd/0000\:00\:10.2/power/control jlgentoo ~ # echo auto >/sys/bus/pci/drivers/uhci_hcd/0000\:00\:10.3/power/control jlgentoo ~ # cat /sys/bus/pci/drivers/*_hcd/0*/power/control auto auto auto auto auto jlgentoo ~ # pm-hibernate Doesn't change anything.Reboots. ---------------------------------------------- Kernel 3.1.9: output from /proc/acpi/wakeup: Device S-state Status Sysfs node PCI0 S5 *disabled no-bus:pci0000:00 USB0 S4 *disabled USB1 S4 *disabled USB2 S4 *disabled USB3 S4 *disabled pci:0000:00:10.0 USB4 S4 *disabled pci:0000:00:10.1 USB5 S4 *disabled pci:0000:00:10.2 USB6 S4 *disabled pci:0000:00:10.3 AC97 S5 *disabled pci:0000:00:11.5 PEXG S5 *disabled pci:0000:00:02.0 PEX0 S5 *disabled pci:0000:00:03.0 PEX1 S5 *disabled pci:0000:00:03.1 PEX2 S5 *disabled pci:0000:00:03.2 PEX3 S5 *disabled pci:0000:00:03.3 UAR1 S5 *disabled pnp:00:08 cat /sys/power/disk [platform] test testproc shutdown reboot Setting it to shutdown doesn't change anything.Works. Setting it to reboot it reboots on hibernate. Funny, isn't it? ----------------------------------------------------------- Perhaps it is USB related because of different output from /proc/acpi/wakeup. I hope all these infos help you (and me). Created attachment 72346 [details]
3.3.0-rc2_lspci-v.txt
Created attachment 72347 [details]
3.3.0-rc2_lsusb-v.txt
Created attachment 72348 [details]
config-3.3.0-rc2
Testet 3.3.0-rc3 all the same. But when I saw the different output from /proc/acpi/wakeup the there was a lightning flash thru my brain. Booted the kernel with "nousb" and guess what... It powers off on hybernate. Strange things happen. But I like USB so this can't be the solution. Btw, removing all platform stuff (except speaker)from my kernel config did not help. Can you try with making USB* wakeup disabled?
echo USB* > /proc/acpi/wakeup to make disabled.
> Tests:
>
> Kernel 3.3.0-rc2:
>
> output from /proc/acpi/wakeup:
>
> Device S-state Status Sysfs node
> PCI0 S5 *disabled no-bus:pci0000:00
> USB0 S4 *disabled
> USB1 S4 *disabled
> USB2 S4 *disabled
> USB3 S4 *enabled pci:0000:00:10.0
> USB4 S4 *enabled pci:0000:00:10.1
> USB5 S4 *enabled pci:0000:00:10.2
> USB6 S4 *enabled pci:0000:00:10.3
> AC97 S5 *disabled pci:0000:00:11.5
> PEXG S5 *disabled pci:0000:00:02.0
> PEX0 S5 *disabled pci:0000:00:03.0
> PEX1 S5 *disabled pci:0000:00:03.1
> PEX2 S5 *disabled pci:0000:00:03.2
> PEX3 S5 *disabled pci:0000:00:03.3
> UAR1 S5 *disabled pnp:00:08
jlgentoo ~ # echo USB* > /proc/acpi/wakeup jlgentoo ~ # cat /proc/acpi/wakeup Device S-state Status Sysfs node PCI0 S5 *disabled no-bus:pci0000:00 USB0 S4 *disabled USB1 S4 *disabled USB2 S4 *disabled USB3 S4 *enabled pci:0000:00:10.0 USB4 S4 *enabled pci:0000:00:10.1 USB5 S4 *enabled pci:0000:00:10.2 USB6 S4 *enabled pci:0000:00:10.3 AC97 S5 *disabled pci:0000:00:11.5 PEXG S5 *disabled pci:0000:00:02.0 PEX0 S5 *disabled pci:0000:00:03.0 PEX1 S5 *disabled pci:0000:00:03.1 PEX2 S5 *disabled pci:0000:00:03.2 PEX3 S5 *disabled pci:0000:00:03.3 UAR1 S5 *disabled pnp:00:08 jlgentoo ~ # pm-hibernate It seems, the file is changed back automaticly. Tried to edit the file with nano and set the enabled to disabled but it is the same old after that. From where does that file get his information or what part of the Kernel does change that file? jlgentoo ~ # ls -l /proc/acpi/wakeup -rw-r--r-- 1 root root 0 10. Feb 11:36 /proc/acpi/wakeup jlgentoo ~ # ls -l /proc/acpi/wakeup -rw-r--r-- 1 root root 0 10. Feb 11:37 /proc/acpi/wakeup jlgentoo ~ # ls -l /proc/acpi/wakeup -rw-r--r-- 1 root root 0 10. Feb 11:38 /proc/acpi/wakeup jlgentoo ~ # echo disabled>/sys/devices/pci0000\:00/0000\:00\:10.0/power/wakeup echo disabled>/sys/devices/pci0000\:00/0000\:00\:10.1/power/wakeup echo disabled>/sys/devices/pci0000\:00/0000\:00\:10.2/power/wakeup echo disabled>/sys/devices/pci0000\:00/0000\:00\:10.3/power/wakeup jlgentoo ~ # cat /proc/acpi/wakeup Device S-state Status Sysfs node PCI0 S5 *disabled no-bus:pci0000:00 USB0 S4 *disabled USB1 S4 *disabled USB2 S4 *disabled USB3 S4 *disabled pci:0000:00:10.0 USB4 S4 *disabled pci:0000:00:10.1 USB5 S4 *disabled pci:0000:00:10.2 USB6 S4 *disabled pci:0000:00:10.3 AC97 S5 *disabled pci:0000:00:11.5 PEXG S5 *disabled pci:0000:00:02.0 PEX0 S5 *disabled pci:0000:00:03.0 PEX1 S5 *disabled pci:0000:00:03.1 PEX2 S5 *disabled pci:0000:00:03.2 PEX3 S5 *disabled pci:0000:00:03.3 UAR1 S5 *disabled pnp:00:08 jlgentoo ~ # Then it powers off on hibernate. After some test with all my USB devices I saw: Only my front-USB (USB 2.0 direct connected with a plug to the pins onboard) is affected. The not powering off problem is only with LowSpeed and FullSpeed devices. (mouse,printer,dvb-t stick). They use uhci_hcd. No problem with HighSpeed devices using ehci_hcd. (harddisk,cardreader) So it is USB related. Plugging these devices in and out does no changes in /proc/acpi/wakeup. Please revert patch 5c12e7856d75f68c and try again. commit 5c12e7856d75f68c1ca8372d6cc76cdbc71763c0 Author: Alan Stern <stern@rowland.harvard.edu> Date: Mon Sep 26 11:25:26 2011 -0400 USB: UHCI: improve comments and logic for root-hub suspend This patch (as1488) improves the comments and logic in uhci-hcd's suspend routine. The existing comments are hard to understand and don't give a good idea of what's really going on. run "git revert 5c12e7856d75f68c1ca8372d6cc76cdbc71763c0" in the kernel git tree. I seem to be hitting the same issue. Starts with 3.2.1, 3.1.10 is okay. I have a different /proc/acpi/wakeup though: Device S-state Status Sysfs node VBTN S4 *enabled PCI0 S5 *disabled no-bus:pci0000:00 PCI1 S5 *enabled pci:0000:00:1e.0 PCI2 S5 *disabled pci:0000:00:1c.0 PCI3 S5 *disabled PCI4 S5 *disabled pci:0000:00:01.0 KBD S3 *enabled pnp:00:06 USB0 S3 *disabled pci:0000:00:1d.0 USB1 S3 *disabled pci:0000:00:1d.1 USB2 S3 *disabled pci:0000:00:1d.2 USB3 S3 *disabled pci:0000:00:1d.3 On 3.2+ the USB devices are enabled. However, if I disable the usb devices the machine still reboots immediately. If I disable *everything* (even those enabled in 3.1) it does shutdown. With acpi=off it does not power off. Will try the patch next. Created attachment 72386 [details] revert use this patch! downloaded from http://kernel.opensuse.org/cgit/kernel/patch/?id=5c12e7856d75f68c1ca8372d6cc76cdbc71763c0 jlgentoo linux-3.2.6 # patch -R --verbose drivers/usb/host/uhci-hcd.c < /home/joerg/Downloads/5c12e7856d75f68c1ca8372d6cc76cdbc71763c0.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |From 5c12e7856d75f68c1ca8372d6cc76cdbc71763c0 Mon Sep 17 00:00:00 2001 |From: Alan Stern <stern@rowland.harvard.edu> |Date: Mon, 26 Sep 2011 15:25:26 +0000 |Subject: USB: UHCI: improve comments and logic for root-hub suspend | |This patch (as1488) improves the comments and logic in uhci-hcd's |suspend routine. The existing comments are hard to understand and |don't give a good idea of what's really going on. | |The question of whether EGSM (Enter Global Suspend Mode) and RD |(enable Resume Detect interrupts) can be useful when they're not both |set is difficult. The spec doesn't give any details on how they |interact with system wakeup, although clearly they are meant to be |used together. To be safe, the patch changes the subroutine so that |neither bit gets set unless they both do. There shouldn't be any |functional changes from this; only systems that are designed badly or |broken in some way need to avoid using those bits. | |Signed-off-by: Alan Stern <stern@rowland.harvard.edu> |Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> |--- |diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c |index fba99b1..c8ae199 100644 |--- a/drivers/usb/host/uhci-hcd.c |+++ b/drivers/usb/host/uhci-hcd.c -------------------------- Patching file drivers/usb/host/uhci-hcd.c using Plan A... Hunk #1 succeeded at 294. Hunk #2 succeeded at 364. Hmm... Ignoring the trailing garbage. done jlgentoo linux-3.2.6 # cd .. jlgentoo src # diff linux-3.1.9/drivers/usb/host/uhci-hcd.c linux-3.2.6/drivers/usb/host/uhci-hcd.c jlgentoo src # lol??? so I just could had to copy the file from 3.1.9 ? ok I will survive: jlgentoo linux-3.2.6 # make oldconfig; make && make modules_install && make install ; eject ;KERNEL_DIR="/usr/src/linux-3.2.6-rc2/" emerge -v1 nvidia-drivers virtualbox-modules --quiet-build=n Lets see, what happens... by the way, before revertpatching: jlgentoo src # diff linux-3.3-rc3/drivers/usb/host/uhci-hcd.c linux-3.2.6/drivers/usb/host/uhci-hcd.c 62c62 < static bool ignore_oc; --- > static int ignore_oc; jlgentoo src # /usr/src/linux-3.2.6-rc2/ had to be /usr/src/linux-3.2.6/ ------------------------------------------ reverting the patch didn't help. After it there was no diff between the revertpatched file and the file from 3.1.9 . Compiled it but the Kernel 3.2.6 behaves as before. I created a fresh linux-3.1.9 directory. Copied the file drivers/usb/host/uhci-hcd.c from 3.3-rc3. After compiling/installing, rebooting, hibernating there is no difference as with the original. So the error can't be that file. Output from /proc/acpi/wakeup where the same as before. @Orion: Which mainboard do you have? I'd like to see a lspci Are only the onboard pin conectors affected or the Backpanel-USB too? Difference between Low/FullSpeed and Highspeed-devices? Reverting 5c12e7856d75f68c1ca8372d6cc76cdbc71763c0 on top of the Fedora 16 kernel had no effect for me either. I have a Dell Dimension 4700: 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express Root Port (rev 04) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation G96 [Quadro FX 580] (rev a1) 03:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) 03:08.0 Ethernet controller: Intel Corporation 82562ET/EZ/GT/GZ - PRO/100 VE (LOM) Ethernet Controller (rev 03) Not sure what you're asking for with "Backpanel-USB" or difference between devices. Problem still exists with 3.3.0-rc7. Are there no other users with that bug? Can anyone of the USB-kernel-devs have a look at it? Interestingly, for me at least, this appears to be triggered by a specific USB device: [ 475.172865] usb 1-1: New USB device found, idVendor=0409, idProduct=0058 [ 475.172875] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 475.172881] usb 1-1: Product: USB2.0 Hub Controller [ 475.172886] usb 1-1: Manufacturer: NEC Corporation If I remove this device, the system stays off. I have another usb hub: [ 1316.877416] usb 1-1: New USB device found, idVendor=0424, idProduct=2504 [ 1316.877422] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 but this one does not cause problems. Can you test the hibernation with kernel parameter "no_console_suspend" and attach the output? This maybe be hard since reboot after hibernation. In the Documentation/power/basic-pm-debugging.txt ># echo platform > /sys/power/disk ># echo disk > /sys/power/state > >which is the default and recommended mode of hibernation. > >Unfortunately, the "platform" mode of hibernation does not work on some >systems >with broken BIOSes. In such cases the "shutdown" mode of hibernation might >work: This maybe caused by the broken Bios. Please attach the output of acpidump. Can you enable usbx wakeup on the 3.1.9 and test hibernation to check whether it also will reboot? bug closed as there is no response from the bug reporter. please feel free to reopen it if the problem still exists in the latest upstream kernel. Bug still exists with latest kernel 3.5.0-rc3 Created attachment 73851 [details]
output of acpidump with kernel 3.5-rc3
jospezial, can you try using git bisect between the 3.1 and 3.2 kernels to find out exactly which commit caused the problem to occur? Hi Alan:
From Com#19 and Com #22, the problems of jospezial and Orion are different. From Com#29, Orion's problem is device's related. But jospezial is similar to the issue of ohci on the Asus board we discuss recently.
Hi jospezial:
Can you find whether bios on your machine provide usb port's jumper? If yes, set it to +5VSB and try again.
I didn't find out how exactly to use git bisect so I did some tests with kernel git snapshots. It must be something between linux-3.1 and linux-3.2-rc1 that did the change but I didn't find time to test the commits between that. I looked at my jumper settings. Back-panel USBPW12 and USBPW34 was set to 5VSB while front-panel USBPW56 and USBPW78 was set to 5V With changing these jumpers I can confirm the change in the power-off on hibernate behavior. Thank you for the hint "similar to the issue of ohci on the Asus board we discuss recently". I found https://bugzilla.kernel.org/show_bug.cgi?id=43081 . I set my bug to a duplicate of the upper were we can go on with the discussion. *** This bug has been marked as a duplicate of bug 43081 *** |