Bugzilla – Bug 157977
After one successfully suspend to RAM, closing the lid on a thinkpad T42p is ignored.
Last modified: 2006-03-21 14:13:25 UTC
While suspend to RAM always works when initiated through KPowersave it is only working *once* when closing the laptop's lid. After awaking the laptop by opening the lid I have to restart powesaved to achieve a successfully suspend to RAM by closing the lid. This behaviour is strange because it worked perfect under SUSE 9.3 and for some time in 10.0. After updating kernel and other suggested packages with YOU it stopped working but I cannot tell when. I tried the newest powersaved packages on SF with no success. I now returned to the original package and applied only the security update as suggested by YOU. My hardware is Thinkpad T42p, 2 GB RAM and I have installed and use VMWare, Linuxant Modem driver and openvpn. All of that were in usage when closing the lid worked. As suggested on the website I attach some logs, in particular a messages excerpt which I created using DEBUG=15 in common. Here are some additional informations regarding versions: # rpm -q powersave dbus-1 hal powersave-0.10.15.2-0.1 dbus-1-0.35.2-8 hal-0.5.4-6.4 # uname -r 2.6.13-15.8-default
Created attachment 72809 [details] Excerpt from /var/log/messages while suspending and resuming
Created attachment 72810 [details] The complete /etc/sysconfig/powersave/ content.
Created attachment 72811 [details] The last /home/taki/bugzilla/suspend2ram.log file
Created attachment 72812 [details] The last /home/taki/bugzilla/suspend2ram.log file
Ok, I think I see it. At the time 16:15:52, restore_after_suspend_to_ram is executed. But this script never returns. Can you please check with ps aux if this script is still active at the point where lidclose is ignored? But there popps up another question, the event RESUME_AFTER_SUSPEND2RAM should time out after about 2 Minutes and a line like similar to that should appear in /var/log/messages: Timeout for event RESUME_AFTER_SUSPEND_TO_RAM with id %d reached, removing it Just to make sure and if this line does not appear, please set SUSPEND2RAM_RESTORE_CLOCK="yes" in /etc/sysconfig/powersave/sleep . But even if the event would time out, ignore_buttons would not be set to false. That's actually a bug but not really related to your problem. Will fix that.
(In reply to comment #5) > Ok, I think I see it. At the time 16:15:52, restore_after_suspend_to_ram is > executed. But this script never returns. Can you please check with ps aux if > this script is still active at the point where lidclose is ignored? Heck, I should have think of that myself... This is the case and I recall having seen the still running restore_after_suspend_to_ram script in the past. After opening the lid and resuming I get the attached output when running ps aux. Could it be timidity that causes the issues? (I did not modify the audio configuration after YaST recognised it while installing the OS). > > But there popps up another question, the event RESUME_AFTER_SUSPEND2RAM should > time out after about 2 Minutes and a line like similar to that should appear in > /var/log/messages: > > Timeout for event RESUME_AFTER_SUSPEND_TO_RAM with id %d reached, removing it I get this line: [powersave]: WARNING (checkEventTimeouts:1313) Timeout for event global.resume.suspend2ram with id 11 reached, removing it. > > Just to make sure and if this line does not appear, please set > SUSPEND2RAM_RESTORE_CLOCK="yes" in /etc/sysconfig/powersave/sleep . > > But even if the event would time out, ignore_buttons would not be set to false. > That's actually a bug but not really related to your problem. Will fix that. > I did not change the value of SUSPEND2RAM_RESTORE_CLOCK because the line appears. If you still need this please instruct me what logs you need... Thanks for helping, Taki
Created attachment 73000 [details] Comment #5: Output of ps aux
> Could it be timidity that causes the issues? (I did not modify the audio > configuration after YaST recognised it while installing the OS). Timidity seems to be involved. Can you please set the following value in /etc/sysconfig/powersave/sleep and retest: SUSPEND2RAM_RESTART_SERVICES="alsasound" > I get this line: > [powersave]: WARNING (checkEventTimeouts:1313) Timeout for event > global.resume.suspend2ram with id 11 reached, removing it. Ok, this part seems fine. > I did not change the value of SUSPEND2RAM_RESTORE_CLOCK because the line > appears. If you still need this please instruct me what logs you need... No, not needed, thanks.
(In reply to comment #8) > Timidity seems to be involved. Can you please set the following value in > /etc/sysconfig/powersave/sleep and retest: > SUSPEND2RAM_RESTART_SERVICES="alsasound" no. It is already in S2RAM_RESTART_SERVICES: Stopping services: ('hsf autofs alsasound openvpn network irda' configured) And that's where it hangs. it hangs when starting alsasound, and it never starts autofs and hsf because it never gets there. Do you need to stop alsasound for suspend to RAM?
(In reply to comment #9) > (In reply to comment #8) > > > Timidity seems to be involved. Can you please set the following value in > > /etc/sysconfig/powersave/sleep and retest: > > SUSPEND2RAM_RESTART_SERVICES="alsasound" > > no. It is already in S2RAM_RESTART_SERVICES: > Stopping services: ('hsf autofs alsasound openvpn network irda' configured) > > And that's where it hangs. it hangs when starting alsasound, and it never > starts autofs and hsf because it never gets there. > > Do you need to stop alsasound for suspend to RAM? > I just tried to play a sound right now and it doesn't work. I probably did not notice that before because I always did a rcpowersaved restart before continuing to work (just to be sure that it worked and my laptop wouldn't get hurt by a malfunction). Trying rcalsasound restart gives me this output: thinkpad:~ # rcalsasound restart Shutting down sound driverERROR: Module snd_mixer_oss is in use ERROR: Module snd_intel8x0 is in use ERROR: Module snd_ac97_codec is in use by snd_intel8x0 ERROR: Module snd_ac97_bus is in use by snd_ac97_codec ERROR: Module snd_pcm is in use by snd_intel8x0,snd_ac97_codec ERROR: Module snd_timer is in use by snd_pcm ERROR: Module snd is in use by snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer failed Starting sound driver: intel8x0 done Could not open sequencer Permission denied Requested buffer size 2048, fragment size 1024 ALSA pcm 'default' set buffer size 60208, period size 3760 bytes TiMidity starting in ALSA server mode Opening sequencer port: 128:0 128:1 128:2 128:3 and sound works as expected and, surprise, the stale script disappeared now! I think this is an evidence that something wents wrong when alsa is restarted. But even after the manual rcalsasound restart closing the lid isn't recognised. I needed alsasound in the list because after resume it didn't work in the past. I did not tried it recently but I will in a few minutes. Thanks for the fast reply!
(In reply to comment #9) [...] > > Do you need to stop alsasound for suspend to RAM? > OK, I just verified that taking out alsasound does not prevent suspend/resume at all. Now also the other services as openvpn restart correctly... I'd say that was it but it's still strange that alsasound doesn't work as expected and that somewhere in time its behaviour changed (needed to be in SUSPEND2RAM_RESTART_SERVICES and now *shouldn't*). If you think that I can help you in any way to trace down what happened, I'd pleased to do so. Just send me instructions... Thanks a lot, Taki
Ok, we already removed rcalsasound restart for 10.1. So maybe Takashi can help here. But I don't know if it is worth to fix because it is a 10.0 issue. Takashi, only comment 10 should be important for you, so no need to read the whole report. And please close the the bug if it is not worth to look at.
The bug that rcalsasound doesn't close /dev/mixer* is fixed recently.