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.