Bugzilla – Bug 116384
Suspend to disk over sleep key button is not working properly
Last modified: 2005-12-09 09:55:03 UTC
HW: HP Omnibook 6100, 1 GHz, It is not clear under which rule the button works. Normaly it should work after one press button but it does´nt work. I have pressed the button more than two times and that with different results. It is´nt plausible how it works. After a different numbers of pressing button suspend to disk starts but this behaviour is not acceptable. Any idea?
Can you please stop powersaved and acpid $ rcpowersaved stop $ rcacpid stop Then do a cat on /proc/acpi/event $ cat /proc/acpi/event Post the output of this while pressing the power button.
Created attachment 49585 [details] cat /proc/acpi/event I did (see logfile).
This looks sane. Did the events get through without a delay?
Please change the debug level in /etc/sysconfig/powersave/common to 15: DEBUG="" --> DEBUG="15" Then restart powersaved, press the sleep button and tell us what comes up in /var/log/messages. Thanks.
hmacht: Will you please take care? This does not seem to be a low-level bug.
Yes, I will.
Created attachment 49691 [details] /var/log/messages First of all the sleep key is working without any delay. (#2/#3) I switched the DebugLevel to 15 (#4) and started powersaved new. 1. I pressed the sleep key. 2. Suspend to disk started immediately (09:31:16 Line 769) 3. and came back well (09:32:30 Line 799) 4. I pressed the sleep key again three or four times with nor reaction. 5. After some minutes supend to disc started obviousely with a delay (09:37:42 Line 1725) 6. Comming back crashed with: APCI-1048: *** Warning: Failed to acquire semaphore [dfffe520|1|0], AE_TIME ... for this Bug please have a look to #114017
To reconstruct the suspend cycle.... line 398: first sleep button occurance Sep 13 09:31:14 ULNZ [powersave]: DIAG (handleHWEventRequest:129) ACPI Event: 'button/sleep SLP 00000080 00000005' ignore buttons: no [...]Systems executes all events for suspend to disk[...] line 854: we are back from resuming Sep 13 09:32:35 ULNZ [powersave]: Info (checkScriptReturn:1359) SCRIPT Event global.resume.suspend2disk finished successfully The next sleep button event comes on line 1342: Sep 13 09:37:40 ULNZ [powersave]: DIAG (handleHWEventRequest:129) ACPI Event: 'button/sleep SLP 00000080 00000006' ignore buttons: no You see the counter? It _is_ the next button event. So there must be a delay between button/sleep_5 and button/sleep_6 somehow. Ulrich, please tell us if this behaviour is reproduceable. I mean, does the first button press work everytime, and doesn't it work anymore after coming back from suspend? For the sixth item from comment #7, please refer to the bug mentioned there(114017). I think this is a different issue. Timo: It seems not to be a powersave problem, sorry ;-)
Just a shot into the dark, but maybe you press the sleep button a bit to short? Is this possible?
cc'ing Thomas (the mighty ASUS fix guy). Did you ever encounter/heard of a delay of ACPI buttons on HP systems as described in comment #1. It seems to be something like: # of key press action 1 ACPI event triggered (button/sleep SLP 00000080 00000005) 2 none 3 none 4 none 5 ACPI event triggered (button/sleep SLP 00000080 00000006)
#8 Key counter = 5 comes from the test before without DEBUG 15. Between counter = 5 and = 6 were 3 or 4 key press. This behaviour is reproduceable. #9 Normal, it can not be to short but I did short press and long press in different time distances. There is no logic recognizable. The Sleep Key is ok and working with w2k with one short key press without failure. I am working with both OS on different discs which I exchange at use? I will test the key function again after a cold start with a detailed protocol if its nessesary.
No. Key counter 5 occured definitely after you changed the debug level to 15. Otherwise it would not appear in the logs.
It might be a silly question, but that 'loss of events' is only occurring after a suspend, not if e.g. the power button is ignored (instead of starting the suspend)?
I checked this in the logs and there is no button ignored. Then we would have ACPI Event: 'button/sleep SLP 00000080 00000006' ignore buttons: yes istead of ACPI Event: 'button/sleep SLP 00000080 00000006' ignore buttons: no But this was already my question from comment 8, if this misbehaviour only occures after a suspend or also with a fresh booted system.
Sorry Holger, I forgot to give you this answers. It seems to be a random error. It occurs not only after a suspend. I can tell you there is no line. What can hide to accept this key? What special test I can do?
No problem. Thanks for the information. Anyway, I have no idea atm. We should wait for trenn to comment on this. Maybe he knows more...
Thomas, any idea from you?
Anything new here? Thomas?
Hmm, maybe this will be fixed with the ASUS buffered key problem. There is a fix for it now, I still have to short it down (#61106). If it's not this I would close this one won't fix. Hmm, marking the bug as a duplicate of #61106, it's easier for the reporter to see what is going on. *** This bug has been marked as a duplicate of 61106 ***