Bug 118353 - (ACPI) power button shuts down on resume from S3
(ACPI) power button shuts down on resume from S3
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
: 132613 140205 (view as bug list)
Depends On:
Blocks: FCMETA_ACPI
  Show dependency treegraph
 
Reported: 2004-03-15 16:34 EST by Dumitru Ciobarcianu
Modified: 2015-01-04 17:05 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-06 00:15:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
My kernel config (31.66 KB, text/plain)
2004-03-15 16:35 EST, Dumitru Ciobarcianu
no flags Details
Bootlog (13.64 KB, text/plain)
2004-03-16 01:49 EST, Dumitru Ciobarcianu
no flags Details

  None (edit)
Description Dumitru Ciobarcianu 2004-03-15 16:34:16 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
Comment 1 Dumitru Ciobarcianu 2004-03-15 16:35:12 EST
Created attachment 98553 [details]
My kernel config
Comment 2 Len Brown 2004-03-15 23:13:55 EST
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 
 
 
Comment 3 Dumitru Ciobarcianu 2004-03-16 01:49:54 EST
Created attachment 98560 [details]
Bootlog
Comment 4 Dumitru Ciobarcianu 2004-03-16 01:54:41 EST
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> :)

Comment 5 Len Brown 2004-03-20 03:07:25 EST
> 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 
 
Comment 6 Dumitru Ciobarcianu 2004-03-20 06:46:36 EST
 
> 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.
Comment 7 Warren Togami 2004-04-16 05:49:17 EDT
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.)
Comment 8 Dumitru Ciobarcianu 2004-04-18 04:00:44 EDT
I get the same thing with kernel-2.6.5-1.326
If I don't kill acpid before suspend, the system will reboot.
Comment 9 Luming Yu 2004-04-26 02:00:09 EDT
Would you please have patch http://bugzilla.kernel.org/attachment.cgi?
id=1214&action=view a try?

Comment 10 Dumitru Ciobarcianu 2004-04-26 14:41:14 EDT
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 :)

Comment 11 cam 2004-05-17 20:11:57 EDT
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.
Comment 12 Bill Nottingham 2004-09-15 17:00:32 EDT
*** Bug 132613 has been marked as a duplicate of this bug. ***
Comment 13 Dave Jones 2004-11-21 16:04:11 EST
how do things behave in the current kernel ?
Comment 14 cam 2004-11-24 19:55:35 EST
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.
Comment 15 Dave Jones 2005-08-04 15:17:10 EDT
This bug has been around for quite a while without any activity, please reopen
if its still a problem with the latest development kernel.
Comment 16 Orion Poplawski 2005-12-22 17:02:53 EST
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"
Comment 17 Dave Jones 2005-12-23 14:03:17 EST
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.
Comment 18 Orion Poplawski 2005-12-23 21:48:23 EST
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.
Comment 19 cam 2005-12-23 23:30:43 EST
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
Comment 20 Linux ACPI Developers 2006-01-17 23:18:56 EST
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.
Comment 21 Len Brown 2006-01-18 04:49:23 EST
*** Bug 140205 has been marked as a duplicate of this bug. ***
Comment 22 Dave Jones 2006-03-06 00:15:42 EST
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.

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