Red Hat Bugzilla – Bug 118353
(ACPI) power button shuts down on resume from S3
Last modified: 2015-01-04 17:05:00 EST
Description of problem: Using kernel-source I rebuilt the kernel with the laptop_mode patch (I don't think it is relevant, just including the info for completness), leaving out the 4G and 4kstacks patches. acpid running. suspending with: ---- /sbin/rmmod uhci_hcd /sbin/cardctl suspend /sbin/clock -w /bin/sync ; /bin/sync ; /bin/sync sleep 1 echo -n mem >/sys/power/state sleep 1 /usr/sbin/hwclock --hctosys /sbin/cardctl resume /sbin/modprobe uhci_hcd ---- On resume the system will shutdown cleanly (shutdown init scripts called). If I kill acpid before suspend and restart it after, the system will run just fine. Is this an kernel or acpid bug ? or both ? Version-Release number of selected component (if applicable): kernel-2.6.4-1.270 How reproducible: Always
Created attachment 98553 [details] My kernel config
I think the problem is that the power-button event you're using to resume from S3 is being received by acpid -- which is configured to shut down the system when it receives power button events. IIR this has been seen before in the past. I don't have a kernel-2.6.4-1.270 handy, can you attach the dmesg to show the ACPICA version it contains? thanks, -Len
Created attachment 98560 [details] Bootlog
Yes, acpid is configured to shutdown on power button events, but this is the first time/kernel it happens to shutdown after resume. <newbie view> Looks like the system does not mark the "pwr button" event as handled after it resumes </newbie> :)
> ACPI: Subsystem revision 20040220 any chance you can try a 2.6.5-based kernel -- it has some event fixes. Also, I don't suppose it makes any difference if you invoke the sleep via echo 3 >/proc/acpi/sleep thanks, -Len
> any chance you can try a 2.6.5-based kernel -- it has some > event fixes. Same thing happens with vanilla 2.6.5-rc2 >Also, I don't suppose it makes any difference if you invoke the sleep via > > echo 3 >/proc/acpi/sleep > > No, it does not.
Please try it with the 2.6.5-1.326+ kernels from rawhide. Do not rebuild your own custom kernel, we need test results from these kernels exactly. (It actually seems to have laptop_mode included, if its existence in /proc is any indicator.)
I get the same thing with kernel-2.6.5-1.326 If I don't kill acpid before suspend, the system will reboot.
Would you please have patch http://bugzilla.kernel.org/attachment.cgi? id=1214&action=view a try?
On top of what I should apply it ? On top of stock 2.6.5 it rejects. I'll try to search for the context and apply it by hand (and hoping I won't screw it up :)
I am seeing similar problems with a laptop that has some ACPI issues (only recently has it been able to suspend/resume and it does not show battery info). I get a lid event when I close the lid - I have put an event script to run echo 3 > /proc/acpi/sleep for that, otherwise the event is ignored. When I open the lid, nothing happens. If I touch a shift key the system wakes but the acpid reports a power button event: [Mon May 17 23:50:36 2004] received event "button/power PWRF 00000080 00000005" [Mon May 17 23:50:36 2004] notifying client 2424[500:500] [Mon May 17 23:50:36 2004] executing action "/sbin/shutdown -h now" [Mon May 17 23:50:36 2004] BEGIN HANDLER MESSAGES I am hoping to rebuild the kernel with the DSDT in initrd patch so I can test my replacement hacked DSDT.
*** Bug 132613 has been marked as a duplicate of this bug. ***
how do things behave in the current kernel ?
2.6.8-1.521, the sleep button works - creating an ACPI event button/sleep SBTN. I have a handler that suspends using echo -n mem > /sys/power/state I suspend in the same way for a lid close. There is still a button/power PWRF event received when unsuspending - even though I suspend with a lid close, and unsuspend by touching a keyboard key (any key, eg. shift). IE I don't go near the power button. I removed the PWRF event handler to avoid spurious shutdowns a long time ago. kernel-2.6.9-1.6_FC2, I had some strange problems with stack traces on unsuspend. Also the battery management went into a strange state, the battery no longer charged, and the power adapter turned off. Eventually worked around by booting with a near-flat battery, entering bios setup and using Fn-F2 to summon battery status panel - then the power adapter turned on again and charging started. Decided not to report the details as it's fringe hardware and bleeding edge kernel.
This bug has been around for quite a while without any activity, please reopen if its still a problem with the latest development kernel.
Okay, I'll bite. With today's rawhide: kernel-2.6.14-1.1777_FC5 I've configured the system to suspend on lid button, which it does beautifully (yay!). When the lid is opened (button released), the system flickers to life briefly before going back into suspend because acpid has received another lid button event. I can then wake it up with the power button as that no longer has any acpi action associated with it. acpid log: [Thu Dec 22 14:54:03 2005] received event "button/lid LID 00000080 00000003" [Thu Dec 22 14:54:03 2005] notifying client 2587[0:0] [Thu Dec 22 14:54:03 2005] executing action "/etc/acpi/actions/suspend" [Thu Dec 22 14:54:03 2005] BEGIN HANDLER MESSAGES [Thu Dec 22 14:54:14 2005] END HANDLER MESSAGES [Thu Dec 22 14:54:14 2005] action exited with status 0 [Thu Dec 22 14:54:14 2005] completed event "button/lid LID 00000080 00000003" [Thu Dec 22 14:54:14 2005] received event "button/lid LID 00000080 00000004" [Thu Dec 22 14:54:14 2005] notifying client 2587[0:0] [Thu Dec 22 14:54:14 2005] executing action "/etc/acpi/actions/suspend" [Thu Dec 22 14:54:14 2005] BEGIN HANDLER MESSAGES [Thu Dec 22 14:54:32 2005] END HANDLER MESSAGES [Thu Dec 22 14:54:32 2005] action exited with status 0 [Thu Dec 22 14:54:32 2005] completed event "button/lid LID 00000080 00000004" [Thu Dec 22 14:54:32 2005] received event "processor CPU0 00000080 00000000" [Thu Dec 22 14:54:32 2005] notifying client 2587[0:0] [Thu Dec 22 14:54:32 2005] completed event "processor CPU0 00000080 00000000" [Thu Dec 22 14:54:32 2005] received event "button/power PWRF 00000080 00000002" [Thu Dec 22 14:54:32 2005] notifying client 2587[0:0] [Thu Dec 22 14:54:32 2005] completed event "button/power PWRF 00000080 00000002" [Thu Dec 22 14:54:32 2005] received event "processor CPU0 00000080 00000000" [Thu Dec 22 14:54:32 2005] notifying client 2587[0:0] [Thu Dec 22 14:54:32 2005] completed event "processor CPU0 00000080 00000000"
I think I've seen this happen myself, but never got around to looking into it. an 'rmmod button' just before doing the actual suspend worked around it, but we really should do something better than that hack.
The following was suggested to me by cam (which I have not tested for myself): open=`grep -c open /proc/acpi/button/lid/LID/state` if [ "$open" = "0" ]; then # sleep script... hwclock --systohc echo -n mem > /sys/power/state hwclock --hctosys fi I'm not sure if this logic should be moved into acpid (will we want to run things upon lid open?) or not. Or whether it should pass different events for opening and closing. In any case, this is slightly different than the power button issue, which I believe is still a problem if you configure the power button to shut the machine down. We still get power button events upon waking from suspend.
Thanks for the credit, orion. Speaking pragmatically I think that: * there will always be some variance in the events reported by different machines, buggy or not; * acpid should report the events with minimal interpretation, which allows for simple scripted user-space workarounds like that script; I keep imagining a self-tuning 'control panel' for laptops that would automate the configuration of sleep on keypress / lid action, as well as providing battery info, wireless control etc. but I've never come close to coding it. (eg. temporarily disable all event handlers and prompt the user to press power, any available suspend / hibernate buttons, close/open the lid, etc. From the resulting events sensible behaviour could be configured) -Cam
This is a known upstream bug with a fix on the way. The fix is for the button driver to have a suspend and resume methods so it can be smart enough to throw away events seen after .suspend and before .resume.
*** Bug 140205 has been marked as a duplicate of this bug. ***
until this gets fixed properly in the upstream kernel, we've added a workaround to pm-suspend/pm-hibernate, which removes the button module and reinserts it after resuming.