Bug 306371

Please specify your powersaved version.

Installed Powersave Versions: 

Moonie:~ # rpm -qa|fgrep power
yast2-powertweak-2.14.0-8
kpowersave-0.7.2-2.1
yast2-power-management-2.14.3-7
powersave-devel-0.15.11-0.2
powersave-libs-0.15.10-3
powersave-0.15.11-0.2

We have to find out if it is kpowersave you does the suspend to RAM on Fn+F4. So please quit kpowersave and try again.

(In reply to comment #0 from Andreas Landhäußer)
> When doing a suspend2ram FN-F4 on a Lenovo Thinkpad X60s, screen doesn't lock,
> even that locking has been specied in kpowersave-menu.
> If suspending with kpowersave screen is being locked.
> powersaved doesn't handle the FN-F4 and FN-F12 anymore due to
> 
> 4100)   HOTKEY="Fn+F4" ;;
> ...
> 4108)   HOTKEY="Fn+F12" ;;
> 
> in /usr/lib/powersave/scripts/thinkpad_acpi_events
> 

(In reply to comment #3 from Holger Macht)
> We have to find out if it is kpowersave you does the suspend to RAM on Fn+F4.
> So please quit kpowersave and try again.
> 

When quitting kpowersave, fn-f4 isn't locking screen. It's working as expected, when using suspend2ram  from kpowersave-menu

Please post the content of the /etc/powersave/events:EVENT_BUTTON_LID_CLOSED variable. Thanks.

Danny, in 10.2, should kpowersave catch the event from HAL, or did this just came in with 10.3?

(In reply to comment #5 from Holger Macht)
> Please post the content of the /etc/powersave/events:EVENT_BUTTON_LID_CLOSED
> variable. Thanks.
> 
> Danny, in 10.2, should kpowersave catch the event from HAL, or did this just
> came in with 10.3?
> 

EVENT_BUTTON_LID_CLOSED="suspend_to_ram"

Sorry for the confusion. I don't remember why I requested the EVENT_BUTTON_LID_CLOSED variable. This hasn't something to do with this issue. Maybe I got confused by another bug...sorry for that.

Ok, I had a look at the kpowersave code. In 10.2, it should catch the button event and should execute the same action as if suspend was called from the menu.

Please run 'lshal -m', press the sleep button and post the output, if any.

(In reply to comment #7 from Holger Macht)
> Sorry for the confusion. I don't remember why I requested the
> EVENT_BUTTON_LID_CLOSED variable. This hasn't something to do with this issue.
> Maybe I got confused by another bug...sorry for that.
> 
> Ok, I had a look at the kpowersave code. In 10.2, it should catch the button
> event and should execute the same action as if suspend was called from the
> menu.
> 
> Please run 'lshal -m', press the sleep button and post the output, if any.
> 


Moonie:~ # lshal -m

Start monitoring devicelist:
-------------------------------------------------
acpi_SLPB condition ButtonPressed = sleep
acpi_BAT0 property battery.remaining_time removed
acpi_BAT0 property battery.charge_level.rate = 0 (0x0)
acpi_BAT0 property battery.charge_level.current = 68090 (0x109fa)
acpi_BAT0 property battery.voltage.current = 16583 (0x40c7)
acpi_BAT0 property battery.reporting.rate = 0 (0x0)
acpi_BAT0 property battery.reporting.current = 68090 (0x109fa)
usb_device_47d_1031_noserial_if0_logicaldev_input removed
usb_device_47d_1031_noserial_if0 removed
usb_device_47d_1031_noserial_usbraw removed
usb_device_47d_1031_noserial removed
usb_device_1199_6804_noserial_if0 removed
usb_device_1199_6804_noserial_usbraw removed
usb_device_1199_6804_noserial removed
usb_device_483_2016_noserial_usbraw removed
usb_device_483_2016_noserial_if0 removed
usb_device_483_2016_noserial removed
usb_device_483_2016_noserial added
usb_device_483_2016_noserial_if0 added
usb_device_483_2016_noserial_usbraw added
usb_device_47d_1031_noserial added
usb_device_47d_1031_noserial_if0 added
usb_device_47d_1031_noserial_usbraw added
usb_device_47d_1031_noserial_if0_logicaldev_input added
usb_device_1199_6804_noserial added
usb_device_1199_6804_noserial_if0 added
usb_device_1199_6804_noserial_usbraw added
acpi_BAT0 property battery.remaining_time = 1842 (0x732) (new)
acpi_BAT0 property battery.charge_level.rate = 15591 (0x3ce7)
acpi_BAT0 property battery.charge_level.current = 68130 (0x10a22)
acpi_BAT0 property battery.voltage.current = 16640 (0x4100)
acpi_BAT0 property battery.reporting.rate = 15591 (0x3ce7)
acpi_BAT0 property battery.reporting.current = 68130 (0x10a22)
acpi_BAT0 property battery.remaining_time = 1580 (0x62c)
acpi_BAT0 property battery.charge_level.rate = 17925 (0x4605)
acpi_BAT0 property battery.charge_level.current = 68240 (0x10a90)
acpi_BAT0 property battery.voltage.current = 16644 (0x4104)
acpi_BAT0 property battery.reporting.rate = 17925 (0x4605)
acpi_BAT0 property battery.reporting.current = 68240 (0x10a90)
acpi_BAT0 property battery.remaining_time = 1517 (0x5ed)
acpi_BAT0 property battery.charge_level.rate = 18295 (0x4777)
acpi_BAT0 property battery.charge_level.current = 68400 (0x10b30)
acpi_BAT0 property battery.voltage.current = 16647 (0x4107)
acpi_BAT0 property battery.reporting.rate = 18295 (0x4777)
acpi_BAT0 property battery.reporting.current = 68400 (0x10b30)
acpi_BAT0 property battery.charge_level.percentage = 90 (0x5a)
acpi_BAT0 property battery.remaining_time = 1494 (0x5d6)
acpi_BAT0 property battery.charge_level.rate = 18214 (0x4726)
acpi_BAT0 property battery.charge_level.current = 68550 (0x10bc6)
acpi_BAT0 property battery.voltage.current = 16649 (0x4109)
acpi_BAT0 property battery.reporting.rate = 18214 (0x4726)
acpi_BAT0 property battery.reporting.current = 68550 (0x10bc6)

Jetzt kommen immer nur noch Meldungen von der Batterie, die geladen wird

Andreas

Danny, this smells like a kpowersave issue I don't think it is one because I didn't hear about any similar reports.

Could you please check if you can open the KPowersave menu if this happen?

Please do also this:
* get the pid of the running KPowersave (ps aux | grep kpowersave | grep -v grep)
* mkdir /tmp/kpowersave
* start: strace -ff -s 1024 -o /tmp/kpowersave/strace -p PID (replace PID with the real pid of KPowersave)
* press FN-F4 (the machine should go to suspend ?!)
* after resume: stop the strace and tar.bz2 /tmp/kpowersave and attach the file to this bug

Please attach also ~/.kde/share/config/kpowersaverc

Created attachment 175940 [details]
strace of kpowersave

Attached, you'll find the output of strace to kpowersave

rz5j@Moonie:~> cat ~/.kde/share/config/kpowersaverc
[General]
ActionOnS2DiskButton=
ActionOnSleepButton=
AlreadyStarted=true

[Performance]
blankSs=true
disableDPMS=true
disableNotifications=false
disableSs=false
specPMSettings=false
specSsSettings=true

[Presentation]
blankSs=false
disableNotifications=false
specPMSettings=false
<EOF>

Yes I'm able to open the kpowersave menu from the system tray right and left mouse button.

You didn't configure a event for the sleep button in KPowersave (ActionOnSleepButton=) so the machine should not go to suspend2ram at all (and this mean also: no lock on Fn+F4)! Please configure a action on the sleep button (in the configure dialog: General settings --> Button Events --> select a action from the combobox for the sleep button)

Because of this I close the bug as INVALID, since you missconfigured your KPowersave (the default is: ActionOnSleepButton=SUSPEND2RAM and lockOnSuspend=true)

I did this on purpose, when the button is set to SUSPEND2RAM, resume is not working as expected, a second  SUSPEND2RAM is being done. Ok Screen is locked. 
Please see main description: I've also modified 
 /usr/lib/powersave/scripts/thinkpad_acpi_events

with the events

4100)   HOTKEY="Fn+F4" ;;
...
4108)   HOTKEY="Fn+F12" ;;

not being used.
 

Only to clarify: if you configure KPowersave to suspend2ram on sleep button events the machine get suspended and also the screen get locked? 

If this is not the case (suspend, but no lock): please enable DPMS again for the actual scheme and retry if the screen get locked.

btw. the settings in  /usr/lib/powersave/scripts/thinkpad_acpi_events doesn't matter for KPowersave, KPowersave get all information from HAL and nothing anymore from powersaved.

To answer your question: Yes screen is locked after resume.

on ActionOnSleepButton=SUSPEND2RAM the resume does no work as expected. the resume by opening the lid, forces another suspend2ram on the second resume, screen is locked.

Since powersaved isn't used anymore, I've disabled the deamon, but this didn't help, still the same double suspend.

Not sure if this was already tested: 

- If you stop powersaved and KPowersave and call as root: s2ram. Do you get the same behavior with the second suspend? 

- Could you may try a newer KPowersave version (not 100% sure if everything would work with this version and 10.2) from here: 
http://download.opensuse.org/repositories/home:/dkukawka/openSUSE_10.2/i586/
Could you try if you get the same behavior?

s2ram is working as if when selecting the s2ram from kpowersave, working as expected.

kpowersave-0.7.3-1.1 is working as my installed 0.7.2-2.1, using right mouse suspend2ram everithing is working as expected

Using FN-F4 resume is causing another suspend2ram, which is then resumed. so no change. Sleep button is  set to supend2ram.

During all tests the screen is locked on the sucessful resume.

 

1.) how did you wake up the machine from suspend? With Fn+F4? Maybe this cause a event that get delivered to the userspace, but it shouldn't if it was used to wake-up. This could be a kernel problem.
2.) could you please do this (with v0.7.3 of KPowersave):

- call 'kdebugdialog --on 0' and click on apply (or OK)
- call 'kpowersave --dbg-trace  > /tmp/kpowersave_log  2>&1'
- check if there is something in /tmp/kpowersave_log (e.g. with 'less')
- Use FN-F4
- machine should go to suspend
- wakeup the machine and attach the logfile (/tmp/kpowersave_log) to this bug as tar.bz2

(In reply to comment #18 from Danny Kukawka)
> 1.) how did you wake up the machine from suspend? With Fn+F4? Maybe this cause
> a event that get delivered to the userspace, but it shouldn't if it was used to
> wake-up. This could be a kernel problem.
> 2.) could you please do this (with v0.7.3 of KPowersave):
> 
> - call 'kdebugdialog --on 0' and click on apply (or OK)
> - call 'kpowersave --dbg-trace  > /tmp/kpowersave_log  2>&1'
> - check if there is something in /tmp/kpowersave_log (e.g. with 'less')
> - Use FN-F4
> - machine should go to suspend
> - wakeup the machine and attach the logfile (/tmp/kpowersave_log) to this bug
> as tar.bz2
> 

1. I'm waking up the system by opening the Lid; never tried to resume with FN+F4

right now I'm quite busy at work, so the 2nd part of the answer takes at least up to Oct 20

Created attachment 177282 [details]
requested logfile of kpowersave with debug options

Found some time to perform the requested logs

Thanks for the log. I could see only one suspend initiated by KPowersave.

Did you get a second suspend after wakeup as you created the log from comment #20? Was the screen locked after resume?

Btw: which HAL version is this?

Yes, system didn't successfuly resume after FN+F4, but when it was fully resumed, screen has been locked. I had to close/open the lid 3 times.

HAL 0.5.8_git20061106-31.3

Sorry to bother you again, but I need a log from the case where you get a second (unintended) suspend (this happend only if you wakeup via lidopen?).

Created attachment 179291 [details]
unintended suspend when using FN_F4 for resume

I'll be adding 2 logs one with FN_F4 to resume, the second with Lid_open.
Both are delivering an unexpected suspend

Created attachment 179292 [details]
log with lid_open

second attachment with log from kpowersave

Only an interposed question: Why are you actually trying to resume with FN-F4? Plain FN should be enough, no?

It's not kpowersave that cause a second suspend as the log show. I reassing this to Seife, maybe he has some ideas. It could be a kernel problem.

(In reply to comment #27 from Holger Macht)
> Only an interposed question: Why are you actually trying to resume with FN-F4?
> Plain FN should be enough, no?
> 

Just used it, since Danny was asking for it. USUALLY I'm just closing and opening the lid, never tried anything else 

no, sorry, i don't have any idea (and i can't make any sense from those kpowersave logs :-)

The only thing i could imagine is that somehow kpowersave and powersave interfere, so stopping powersaved (chkconfig powersaved off; rcpowersaved stop) would be something worth trying.

Created attachment 184874 [details]
/var/log/pm-suspend.log of partially failed suspend.

did as you have suggested. FN-F4 didn't succeed. after restarting and enabling powersaved, even kpowersave suspend didnd succeed. I rebooted the system, which then went into suspend!, after resuming reboot went on.

I'm total confused. Without powersave you couldn't suspend? What mean 'partially failed' exactly?

Btw. are you sure it is a second suspend and not a shutdown/reboot?

I just did what you have suggested, maybe I missunderstood.

I did 
chkconfig powersaved off; rcpowersaved stop

then I tried to FN-F4 since I didn't know what you had in mind instead ...

Afer receiving the error I tried 
chkconfig powersaved on; rcpowersaved start

but in the /var/log/messages there had been errors, so I decided to 

shutdown -r now

and the reboot went into a suspend.

So please tell me, what I should have done after you have added your reply

Comment #30 From Stefan Seyfried  2007-11-27 06:32:46 MST

1.) rcpowersaved stop
2.) restart KPowersave
3.) if you configured KPowersave to suspend2ram on lidclose: close the lid
4.) reopen the lid
5.) check what happen. Do the machine resume correcty or do you get a second suspend as before reported?

Did as you requested, system went into suspend, when opening the lid, it didn'd awake, but went into suspend again. Finally FN worked. Still 2 times suspend 

Since this happen also without powersaved and KPowersave call suspend only once: I would tip on a kernel problem. I reassing to the kernel guys

Try doing powersave -u, twice. Wake machine up by powerbutton, not lid or anything. Tell me if it works.

(In reply to comment #37 from Pavel Machek)
> Try doing powersave -u, twice. Wake machine up by powerbutton, not lid or
> anything. Tell me if it works.
> 

I did a powersave -u as User; system went into suspend to ram and woke up when pressing power button. Screen wasn't locked!

again I did a powersave -u ; powersave -u 
System was waken up by Power button, but suspended again because of the second powersave -u. Was waken up by Power button.

The display wasn't locked on any of the actions when system was alive again ...

Okay, I guess that means that kernel works as designed and problem is somewhere in higher layers. I'll let seife help here...

powersave -u will not lock the screen. The screen is only locked if you suspend via kpowersave (either by fn-f4 or by clicking suspend from the menu).
The problem here was the double suspend when suspending from kpowersave that we should investigate. Unfortunately i have no real idea where this might come from. It does not happen on my X32 on 10.3 and / or FACTORY ;-)

Ok, Back on track.
Comment #30 was about powersaved (the system daemon) interfering with kpowersave. On 10.2, powersaved should not be needed to suspend anymore, so stopping it and trying again was my recommendation.

Then it did not work because of

Tue Nov 27 14:38:07 CET 2007: done running suspend hooks.
+ /usr/sbin/s2ram
s2ram_do: Device or resource busy
Switching from vt7 to vt1
fbcon fb0 state 1
fbcon fb0 state 0
switching back to vt7
+ RET=16
+ set +x
Tue Nov 27 14:38:09 CET 2007: running resume hooks.

Which is generally the case when stopping the processes fails.
I would ask you to reproduce this problem without any binary-only modules loaded (vmware / dazuko? / cisco_ipsec?) because they can easily cause such failures and are undebuggable by us.

Also, the output of "dmesg" after a failed suspend would be interesting.

Created attachment 203007 [details]
output of dmesg after resume

I've stopped vmware. dazuko and cisco_ipsec. Anyways the problem continues. dmesg.output is attached.

But this time it looks like the machine went to sleep:

ACPI: PCI interrupt for device 0000:00:1b.0 disabled
Disabling non-boot CPUs ...
CPU 1 is now offline
SMP alternatives: switching to UP code
CPU1 is down
 hwsleep-0322 [00] enter_sleep_state     : Entering sleep state [S3]
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Back to C!
Enabling non-boot CPUs ...
SMP alternatives: switching to SMP code
Booting processor 1/1 eip 3000
Initializing CPU#1
Calibrating delay using timer specific routine.. 3325.13 BogoMIPS (lpj=6650276)

Could it be that you have Wake-On-Lan enabled and some ethernet packet wakes up the machine immediately after it goes into suspend?

Can you check your pm-suspend.log if there is the "device or resource busy" message still there?

Created attachment 203101 [details]
content of /var/log/pm-suspend.log

suspend2ram still behaving as described in the bug.
when resuming a second suspend is generated, system is fully resumed after the second resume. no busy devices in /var/log/pm-suspend.log

Just for clarification,

system is suspending on FN-F4 there is NO problem. 
The resume is causing a second suspend. which need to be ended by pressing FN

Ok. I still have no real idea why this happens. :-(

We are still talking about 10.2 here, right?

Please check that /etc/pm/config still contains

SUSPEND_MODULES="button"

I don't see the button module unloaded in your log, which might well be the reason for the second suspend.

Arrrg, no it's 10.3 and there is no config anymore, sorry about this. I upgraded to 10.3 on 2007-09-22

Ok, no problem. Well, another one.
The old kernels had the problem that after resume, you often (depending on vendor and BIOS) got a button_power event, which we needed to ignore.
We did this by simply removing the button module before suspend - so there was no driver to deliver the event.
This should be fixed now with newer kernels (definitely with the 10.3 kernel), so it should not be a problem anymore. However, i have no other idea how this can happen, so please create a file /etc/pm/config.d/button-test (yes, the location moved... dont ask) with the content

SUSPEND_MODULES="button"

and try again. You should see something like

===== Tue Apr  1 10:21:30 CEST 2008: running hook: /usr/lib/pm-utils/sleep.d/50modules =====
trying to unload: button

in your /var/log/pm-suspend.log after resume.
If this fixes your problem, we'll just file it under the "weird machine that needs weird workarounds"-Section ;-)

Created attachment 206325 [details]
excerpt from /var/log/allmessages

made the suggested change, but system behaves as before. I've attached an excerpt from /var/log/allmessages since /var/log/pm-suspend.log is being overwritten on any suspend, and since we are doing 2 suspend implicitly, only the last is being logged. I'm pretty sure in allmessages there are two suspends.

Please check if there is a line
"trying to unload: button"
in pm-suspend.log (even if we are suspending twice, the module is unloaded / reloaded again :-)

maybe just a "grep button /var/log/pm-suspend.log"

ok, i found something:
Apr  4 17:12:39 Moonie acpid: executing action "/etc/acpi/sleep.sh"

please check the following:
- which package does /etc/acpi/sleep.sh belong to? ("rpm -qf /etc/acpi/sleep.sh")
- what is in the acpid event files? ("grep . /etc/acpi/events/*")

It would be great if you could attach/paste the output of those two commads to this bugreport.

Moonie:/home/rz5j # rpm -qf /etc/acpi/sleep.sh
file /etc/acpi/sleep.sh is not owned by any package

think I've introduced it when reading an ubuntu howto, even that OpsenSuSE isn't 
Ubuntu ;-) But grasping the smallest straws

Moonie:/home/rz5j # grep . /etc/acpi/events/* 
/etc/acpi/events/acpid_thinkpad_hotkeys:# dockutils
/etc/acpi/events/acpid_thinkpad_hotkeys:#
/etc/acpi/events/acpid_thinkpad_hotkeys:# Pass over all ibm_acpi events to the dockhandler to get dock/undock
/etc/acpi/events/acpid_thinkpad_hotkeys:# requests
/etc/acpi/events/acpid_thinkpad_hotkeys:event=ibm/.*
/etc/acpi/events/acpid_thinkpad_hotkeys:action=/usr/lib/hotkey-setup/thinkpad_hotkey_handler "%e"
/etc/acpi/events/blank:# /etc/acpi/events/blank
/etc/acpi/events/blank:# This is called when the user presses Fn-F3 and calls
/etc/acpi/events/blank:# /etc/acpi/blank.sh for further processing.
/etc/acpi/events/blank:event=ibm/hotkey HKEY 00000080 00001003
/etc/acpi/events/blank:action=/etc/acpi/blank.sh
/etc/acpi/events/default:# This is a dummy config file to avoid
/etc/acpi/events/default:# that acpid processes any ACPI events.
/etc/acpi/events/default:#
/etc/acpi/events/default:# This should be the default configuration
/etc/acpi/events/default:# as the acpid should only serve to forward
/etc/acpi/events/default:# ACPI events.
/etc/acpi/events/default:# Other programs such as powersaved or special key
/etc/acpi/events/default:# handler programs should process ACPI events
/etc/acpi/events/dockutils_events:# dockutils
/etc/acpi/events/dockutils_events:#
/etc/acpi/events/dockutils_events:# Pass over all ibm_acpi events to the dockhandler to get dock/undock
/etc/acpi/events/dockutils_events:# requests
/etc/acpi/events/dockutils_events:event=ibm/.*
/etc/acpi/events/dockutils_events:action=/usr/lib/dockutils/dockhandler "%e"
/etc/acpi/events/lid:# /etc/acpi/events/lid
/etc/acpi/events/lid:# This is called when the lid is opened/closed and calls
/etc/acpi/events/lid:# /etc/acpi/lid.sh for further processing.
/etc/acpi/events/lid:event=button/lid
/etc/acpi/events/lid:action=/etc/acpi/lid.sh
/etc/acpi/events/lm_ac_adapter:event=ac_adapter/etc/acpi/events/lm_ac_adapter:action=/etc/acpi/actions/lm_ac_adapter.sh %e
/etc/acpi/events/lm_battery:event=battery.*
/etc/acpi/events/lm_battery:action=/etc/acpi/actions/lm_battery.sh %e
/etc/acpi/events/lm_lid:event=button[ /]lid
/etc/acpi/events/lm_lid:action=/etc/acpi/actions/lm_lid.sh %e
/etc/acpi/events/powerbtn:# /etc/acpi/events/powerbtn
/etc/acpi/events/powerbtn:# This is called when the user presses the power button and calls
/etc/acpi/events/powerbtn:# /etc/acpi/powerbtn.sh for further processing.
/etc/acpi/events/powerbtn:# Optionally you can specify the placeholder %e. It will pass
/etc/acpi/events/powerbtn:# through the whole kernel event message to the program you've
/etc/acpi/events/powerbtn:# specified.
/etc/acpi/events/powerbtn:# We need to react on "button power.*" and "button/power.*" because
/etc/acpi/events/powerbtn:# of kernel changes.
/etc/acpi/events/powerbtn:event=button[ /]power/etc/acpi/events/sleepbtn:# This is called when the user presses Fn-F4 and calls
/etc/acpi/events/sleepbtn:# /etc/acpi/sleepbtn.sh for further processing.
/etc/acpi/events/sleepbtn:event=(button|ibm)/(sleep|hotkey HKEY 00000080 00001004)
/etc/acpi/events/sleepbtn:action=/etc/acpi/sleep.sh
/etc/acpi/events/suspend:# /etc/acpi/events/suspend
/etc/acpi/events/suspend:# This is called when the user presses Fn-F12 and calls
/etc/acpi/events/suspend:# /etc/acpi/suspend.sh for further processing.
/etc/acpi/events/suspend:event=ibm/hotkey HKEY 00000080 0000100c
/etc/acpi/events/suspend:action=/etc/acpi/suspend.sh
/etc/acpi/events/video:# /etc/acpi/events/video
/etc/acpi/events/video:# This is called when the user presses Fn-F7
/etc/acpi/events/video:event=ibm/hotkey HKEY 00000080 00001007
/etc/acpi/events/video:action=/etc/acpi/video.sh

/etc/acpi/events/powerbtn:action=/etc/acpi/powerbtn.sh
/etc/acpi/events/sleepbtn:# /etc/acpi/events/sleepbtn

okay, there is lots of crap in /etc/acpi/events that was not installed by suse packages:
/etc/acpi/events/sleepbtn
/etc/acpi/events/powerbtn
/etc/acpi/events/video
/etc/acpi/events/suspend
/etc/acpi/events/lm_lid
/etc/acpi/events/blank

remove those, restart acpid and the double suspend is gone, i'm sure.

I've removed those and the scripts in /etc/acpi, after this everything working. Thanks a lot for your efforts, solving a user problem not being a bug