Distribution: debian etch Hardware Environment: asus A7V motherboard, athlon thunderbird 950 CPU Software Environment: debian etch i386 Problem Description: System powers back up immediately after suspend-to-ram. Worked around by running echo PWRB > /proc/acpi/wakeup Steps to reproduce: After booting the system, any attempt to suspend to ram results in the system suspending (I can hear the fans go off), but resuming immediately. I do have a workaround though: After booting, this system shows in /proc/acpi/wakeup: Device S-state Status Sysfs node PWRB S5 *enabled PCI0 S4 disabled no-bus:pci0000:00 USB0 S4 disabled pci:0000:00:04.2 USB1 S4 disabled pci:0000:00:04.3 If I run echo PWRB > /proc/acpi/wakeup, 1- the kernel complains that "ACPI: 'PCI0' and 'PWRB' have the same GPE, can't disable/enable one seperately" 2- /proc/acpi/wakeup now shows: Device S-state Status Sysfs node PWRB S5 *disabled PCI0 S4 disabled no-bus:pci0000:00 USB0 S4 disabled pci:0000:00:04.2 USB1 S4 disabled pci:0000:00:04.3 3- The system can now be suspended, and it will resume normally when I press the power button. This is not a recent regression, the system has been like that since I first got suspend working. If I run echo PWRB > /proc/acpi/wakeup a second time, 1- The kernel complains again, "ACPI: 'PCI0' and 'PWRB' have the same GPE, can't disable/enable one seperately" 2- /proc/acpi/wakeup now shows: Device S-state Status Sysfs node PWRB S5 *enabled PCI0 S4 enabled no-bus:pci0000:00 USB0 S4 disabled pci:0000:00:04.2 USB1 S4 disabled pci:0000:00:04.3 3- Any attempt to suspend to ram will once again result in the system suspending and resuming immediately.
Created attachment 15837 [details] acpidump output
Well, again that Power button shares the same GPE with another device, PCI0 in this case. This is a violation of ACPI spec. As power button GPE is a RUN_WAKE GPE that should be enabled at both runtime and system sleep state, it should be different from any other device' wakeup GPE (gotten from _PRW) which should be disabled at runtime. In this case, GPE 0x0B is enabled before system enter S3 for power button. As a result, any interrupts from PCI0 may resume the system.
A question: does S3 work in Windows?
I have absolutely no idea... sorry :/
Created attachment 15983 [details] patch: disable pme please apply this patch and see if it works for you.
I'm currently out of the country, I should be able to test this shortly after I come back on may 29th.
Created attachment 16122 [details] try the debug patch Please apply the attached patch and see whether it can work for you. Of course the patch in comment #5 is also required.
I applied the patch from comment #5 to a 2.6.24.7 kernel and suspend/resume now works correctly on that machine. /proc/acpi/wakeup is identical to what it used to be after a clean boot as described in the initial report. Regarding the patch from comment #7: it did not apply to either a clean 2.6.24.7 or 2.6.25.4 tree. I could probably apply it by hand, but would this be of any help considering that the patch from comment #5 alone seems to fix the issue already ? Thanks,
Thanks for the test. Only the patch in comment #5 can fix the issue. And the patch in comment #7 can't fix the issue directly, but it can avoid some potential issues.
I am now running 2.6.26 in that machine, with both patches applied. Suspend/resume works fine in that configuration. I also verified that the machine immediately resumes if suspended with a stock 2.6.26 kernel.
Yes, the patch works for you and we have root caused the problem. But unfortunately, the patch is not for upstream. we still don't have a proposal to fix it in upstream kernel. So I'm afraid we can not resolve this bug right now... :(
Created attachment 17498 [details] patch: don't set Power Button GPE as run_wake if Fixed button is used Please try this patch and see if it helps.
hey, walken, any updates? can you try the patch I attached in comment #12 please?
Whoops, sorry, just noticed the updates. I'll make sure to test within a couple days or less.
I tried the patch from comment #12 (I tried it over a 2.6.24.7 kernel as it's what I use on that host at this time, but the patch did apply cleanly). Sadly it did not work - the machine did resume immediately after suspend. /proc/acpi/wakeup does show PWRB as enabled (no idea if this is what the patch was trying to change or not).
Created attachment 17710 [details] patch: don't set Power Button GPE as run_wake if Fixed button is used sorry, please try this one.
Does not work either... same observations as with the previous patch. Not sure if this is any help, but I do not see any PNP0C0C device listed in /sys/devices/pnp*/*/id ??? (I see the following: /sys/devices/pnp0/00:00/id:PNP0a03 /sys/devices/pnp0/00:01/id:PNP0c02 /sys/devices/pnp0/00:02/id:PNP0200 /sys/devices/pnp0/00:03/id:PNP0b00 /sys/devices/pnp0/00:04/id:PNP0c04 /sys/devices/pnp0/00:05/id:PNP0800 /sys/devices/pnp0/00:06/id:PNP0c02 /sys/devices/pnp0/00:07/id:PNP0c02 /sys/devices/pnp0/00:08/id:PNP0003 /sys/devices/pnp0/00:09/id:PNP0103 )
Created attachment 17722 [details] patch: don't set Power Button GPE as run_wake if Fixed button is used oops, fix a typo, please try this refreshed patch...
Still no luck with that patch. I decided to add some debug printk's in there, hope the following might help. The code you modified gets executed 4 times at boot time, with device->pnp.hardware_id equal to "PNP0C0C", "PNP0A03", "" and "". I suppose this matches the 4 devices in my /proc/acpi/wakeup file. acpi_gbl_FADT.flags & ACPI_FADT_POWER_BUTTON is FALSE. If I take your last patch and revert the polarity of the ACPI_FADT_POWER_BUTTON test again, the machine *still* resumes immediately after a suspend. However, the content of proc/acpi/wakeup is now different: PWRB now shows a status of "enabled" (no star) instead of "*enabled".
Created attachment 17723 [details] patch: don't set Power Button GPE as run_wake if Fixed button is used oops. forget to clear another flag. the button device is set to wakeup device again once ACPI button driver is loaded. clear this flag in scan.c.
Success ! This last patch does work. The machine now suspends fine. There is no PWRB line in /proc/acpi/wakeup anymore, but the button still works (i.e. gets acpid to run the suspend scripts). Very nice :)
great news. :) I'll try to push this patch upstream. Mark this bug as Resolved.
patch in comment #20 applied to acpi-test
shipped in linux-2.6.28-rc1 closed commit faee816b1502385dc9bc5abf2960d1cc645844d1 Author: Zhang Rui <rui.zhang@intel.com> Date: Fri Sep 12 11:12:25 2008 +0800 ACPI: don't enable control method power button as wakeup device when Fixed Power button is used
hi, walken, please get the latest kernel source, revert the patch in comment #20, can you reproduce the problem any more? if yes, please attach the output of " grep . /sys/bus/pci/devices/*/power/wakeup", set these files to "disabled", and retry.
Fine, I'll try with the latest 2.6.28 RC....
So I tried 2.6.28-rc6 with the comment #20 patch reversed.... Summary: it works! The machine suspends correctly and resumes fine with a press of the power button. Details: % cat /proc/acpi/wakeup Device S-state Status Sysfs node PWRB S5 *enabled PCI0 S4 disabled no-bus:pci0000:00 USB0 S4 disabled pci:0000:00:04.2 USB1 S4 disabled pci:0000:00:04.3 % grep . /sys/bus/pci/devices/*/power/wakeup /sys/bus/pci/devices/0000:00:04.2/power/wakeup:disabled /sys/bus/pci/devices/0000:00:04.3/power/wakeup:disabled /sys/bus/pci/devices/0000:00:09.0/power/wakeup:disabled /sys/bus/pci/devices/0000:00:0b.0/power/wakeup:disabled /sys/bus/pci/devices/0000:00:0b.1/power/wakeup:disabled /sys/bus/pci/devices/0000:00:0b.2/power/wakeup:disabled Any attempt to run "echo PWRB > /proc/acpi/wakeup" still switches both the PWRB and PCI0 entries status and results in the "ACPI: 'PCI0' and 'PWRB' have the same GPE, can't disable/enable one seperately" being logged. But, suspend still works in any case and the various wakeup entries in /sys still show disabled. Hope this helps,
With Zhang's patch from bug 12091 comment #9: % cat /proc/acpi/wakeup Device S-state Status Sysfs node PWRB S5 *enabled PCI0 S4 *enabled no-bus:pci0000:00 USB0 S4 disabled pci:0000:00:04.2 USB1 S4 disabled pci:0000:00:04.3 % grep . /sys/bus/pci/devices/*/power/wakeup /sys/bus/pci/devices/0000:00:04.2/power/wakeup:disabled /sys/bus/pci/devices/0000:00:04.3/power/wakeup:disabled /sys/bus/pci/devices/0000:00:09.0/power/wakeup:disabled /sys/bus/pci/devices/0000:00:0b.0/power/wakeup:disabled /sys/bus/pci/devices/0000:00:0b.1/power/wakeup:disabled /sys/bus/pci/devices/0000:00:0b.2/power/wakeup:disabled System still suspends and resume fine.
can you please do the following test: 1. PCI0 disabled echo enabled > /sys/bus/pci/devices/0000:00:0b.0{0000:00:0b.1, 0000:00:0b.2}/power/wakeup suspend, does the problem appears again? 2. PCI0 enabled echo enabled > /sys/bus/pci/devices/0000:00:0b.0{0000:00:0b.1, 0000:00:0b.2}/power/wakeup suspend, does the problem appears again?
Test 1: % cat /proc/acpi/wakeup Device S-state Status Sysfs node PWRB S5 *disabled PCI0 S4 *disabled no-bus:pci0000:00 USB0 S4 disabled pci:0000:00:04.2 USB1 S4 disabled pci:0000:00:04.3 % grep . /sys/bus/pci/devices/*/power/wakeup /sys/bus/pci/devices/0000:00:04.2/power/wakeup:disabled /sys/bus/pci/devices/0000:00:04.3/power/wakeup:disabled /sys/bus/pci/devices/0000:00:09.0/power/wakeup:disabled /sys/bus/pci/devices/0000:00:0b.0/power/wakeup:enabled /sys/bus/pci/devices/0000:00:0b.1/power/wakeup:enabled /sys/bus/pci/devices/0000:00:0b.2/power/wakeup:enabled Machine suspends/resume fine in that configuration. Test 2: % cat /proc/acpi/wakeup Device S-state Status Sysfs node PWRB S5 *enabled PCI0 S4 *enabled no-bus:pci0000:00 USB0 S4 disabled pci:0000:00:04.2 USB1 S4 disabled pci:0000:00:04.3 % grep . /sys/bus/pci/devices/*/power/wakeup /sys/bus/pci/devices/0000:00:04.2/power/wakeup:disabled /sys/bus/pci/devices/0000:00:04.3/power/wakeup:disabled /sys/bus/pci/devices/0000:00:09.0/power/wakeup:disabled /sys/bus/pci/devices/0000:00:0b.0/power/wakeup:enabled /sys/bus/pci/devices/0000:00:0b.1/power/wakeup:enabled /sys/bus/pci/devices/0000:00:0b.2/power/wakeup:enabled Machine won't suspend (or it does, but resumes immediately) in this configuration.