powersaved and ACPI standby (suspend to RAM)
Hi, I have SuSE 9.1 professional on IBM Thinkpad T42p laptop and I am using powersaved to manage power, cpu frequency change etc. So far, throttling/dethrottling works very well. It is the best power utility I have seen in any of the distributions that works well out of the box. My only complaint is that powersaved seems to crash and restart after ACPI standby. I have configured lid close to go to standby (ACPI S3) and lid open to awake up the laptop. The standby works reliably. And the laptop also awakes up to a working stand reliably. Only that the powersaved daemon seems to have crashed and restarted (the process ids for powersaved are different before and after standby). After CPU, the CPU is no longer throttling if I remove the power. kpowersave in KDE system tray does not display any icon but empty space. I have to do pkill powersaved rcpowersaved restart and kpowersave, throttling etc. start working as expected. Is there any way to figure out why powersaved is crashing and make it stop from crashing? thanks, Osho __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Fri, Sep 03, 2004 at 05:40:27PM -0700, Osho GG wrote:
Hi,
I have SuSE 9.1 professional on IBM Thinkpad T42p laptop and I am using powersaved to manage power, cpu frequency change etc. So far, throttling/dethrottling works very well. It is the best power utility I have seen in any of the distributions that works well out of the box.
Thanks. It will even be better in 9.2 ;-)
My only complaint is that powersaved seems to crash and restart after ACPI standby. I have configured lid close to go to standby (ACPI S3) and lid open to awake up the laptop. The standby works reliably. And the laptop also awakes up to a working stand reliably.
That's nice to hear, i have yet to get my hands on a machine where S3 works reliably. Are you using the SUSE update kernels or some newer 2.6.8... self compiled ones?
Only that the powersaved daemon seems to have crashed and restarted (the process ids for powersaved are different before and after standby).
I cannot really think of what would cause this, since powersaved should not restart itself. Be careful not to confuse the different "powersave" log messages in syslog since the proxy script also logs its pid and it of course is a new proxy after resume. Could you verify with "pidof powersaved" before and after suspend to RAM?
After CPU, the CPU is no longer throttling if I remove the power. kpowersave in KDE system tray does not display any icon but empty space.
I have to do
pkill powersaved rcpowersaved restart
so it seems the powersaved is just hanging somewhere. You could try to find out the PID with pidof powersaved strace -p PID substituting PID with the number you got from pidof. I am afraid it is just hanging on some unfinished socket request. Ah! Try "powersave -c" after resume, this just sends a query for the current cpufreq mode to the daemon via the socket, but we once had a case where we needed one socket connection after resume to kick powersaved back to life, maybe this is a similar issue. To be honest: the whole suspend-to-RAM code paths are rather untested since i had no machine with working S3 available.
and kpowersave, throttling etc. start working as expected.
Is there any way to figure out why powersaved is crashing and make it stop from crashing?
I don't think it is really crashed, i think it is just hanging. If you can bring it back to life with "powersave -c" it will be very easy, otherwise i don't know yet. Thanks for the report! -- Stefan Seyfried
On Sat, 4 Sep 2004 11:22:27 +0200, Stefan Seyfried
On Fri, Sep 03, 2004 at 05:40:27PM -0700, Osho GG wrote:
My only complaint is that powersaved seems to crash and restart after ACPI standby. I have configured lid close to go to standby (ACPI S3) and lid open to awake up the laptop. The standby works reliably. And the laptop also awakes up to a working stand reliably.
That's nice to hear, i have yet to get my hands on a machine where S3 works reliably. Are you using the SUSE update kernels or some newer 2.6.8... self compiled ones?
I am using 2.6.8.1 patched with acpi-20040715-2.6.8, bootsplash-3.1.4-sp3, bk-cpufreq and cpufreq-speedstep-dothan-3 patches. I have also compiled all the ACPI modules in the kernel (not sure if that matters though).
Only that the powersaved daemon seems to have crashed and restarted (the process ids for powersaved are different before and after standby).
I cannot really think of what would cause this, since powersaved should not restart itself. Be careful not to confuse the different "powersave" log messages in syslog since the proxy script also logs its pid and it of course is a new proxy after resume. Could you verify with "pidof powersaved" before and after suspend to RAM?
Before standby, pidof powersaved gives 13167. After standby, pidof powersaved gives 20493. I tried doing powersave -c at this point but that just seemed to hang. Doing strace -p 20493 gives Process 20493 attached - interrupt to quit waitpid(20494, So, I did ps -aef | grep 20494 to find out which process 20494 is. I got root 20494 20493 0 01:28 ? 00:00:00 /bin/bash /usr/sbin/powersave_proxy global.resume.standby root 21185 20494 0 01:28 ? 00:00:00 /usr/bin/powersave -c So, I guessed that 20494 is the process that is really stuck. So, I did kill 20494. Now, strace -p 20493 gives more messages after waitpid. Process 20493 attached - interrupt to quit waitpid(20494, [WIFSIGNALED(s) && WTERMSIG(s) == SIGTERM], 0) = 20494 --- SIGCHLD (Child exited) @ 0 (0) --- time([1094320778]) = 1094320778 rt_sigaction(SIGPIPE, {0x401d3f60, [], 0}, {SIG_DFL}, 8) = 0 send(3, "<30>Sep 4 10:59:38 [powersaved]"..., 68, 0) = 68 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 time([1094320778]) = 1094320778 rt_sigaction(SIGPIPE, {0x401d3f60, [], 0}, {SIG_DFL}, 8) = 0 send(3, "<30>Sep 4 10:59:38 [powersaved]"..., 134, 0) = 134 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 time([1094320778]) = 1094320778 rt_sigaction(SIGPIPE, {0x401d3f60, [], 0}, {SIG_DFL}, 8) = 0 send(3, "<28>Sep 4 10:59:38 [powersaved]"..., 189, 0) = 189 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 exit_group(0) = ? Process 20493 detached I tried doing pidof powersaved at this point and it resulted in nothing. So, I guess powersaved is no longer running. I also got a little warning from kpowersave telling me to restart rcpowersaved. I did rcpowersaved restart and everything is back working as expected (CPU frequency is getting throttled as seen in /proc/cpuinfo for example). Sorry if this was too much information. thanks, Osho
On Sat, Sep 04, 2004 at 11:08:54AM -0700, Osho GG wrote:
I am using 2.6.8.1 patched with acpi-20040715-2.6.8,
ok, since a lot has improved since 2.6.5 it is more likely to work :-)
Before standby, pidof powersaved gives 13167.
After standby, pidof powersaved gives 20493.
I cannot explain why this happens, but i am not entirely familiar with the intimate details of the daemon code :-(
I tried doing powersave -c at this point but that just seemed to hang.
Doing strace -p 20493 gives
Process 20493 attached - interrupt to quit waitpid(20494,
So, I did ps -aef | grep 20494 to find out which process 20494 is. I got
root 20494 20493 0 01:28 ? 00:00:00 /bin/bash /usr/sbin/powersave_proxy global.resume.standby root 21185 20494 0 01:28 ? 00:00:00 /usr/bin/powersave -c
So, I guessed that 20494 is the process that is really stuck. So, I did kill 20494.
you can try to remove the "$POWERSAVE_BIN -c" statement from /usr/sbin/powersave_proxy in the resume_after_standby function, (it is on line 779 in my version, but this may be an edited one) but to be honest, i think this is just a symptom and not the cause.
Now, strace -p 20493 gives more messages after waitpid.
Process 20493 attached - interrupt to quit waitpid(20494, [WIFSIGNALED(s) && WTERMSIG(s) == SIGTERM], 0) = 20494 --- SIGCHLD (Child exited) @ 0 (0) --- time([1094320778]) = 1094320778 rt_sigaction(SIGPIPE, {0x401d3f60, [], 0}, {SIG_DFL}, 8) = 0 send(3, "<30>Sep 4 10:59:38 [powersaved]"..., 68, 0) = 68 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 time([1094320778]) = 1094320778 rt_sigaction(SIGPIPE, {0x401d3f60, [], 0}, {SIG_DFL}, 8) = 0 send(3, "<30>Sep 4 10:59:38 [powersaved]"..., 134, 0) = 134 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 time([1094320778]) = 1094320778 rt_sigaction(SIGPIPE, {0x401d3f60, [], 0}, {SIG_DFL}, 8) = 0 send(3, "<28>Sep 4 10:59:38 [powersaved]"..., 189, 0) = 189 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 exit_group(0) = ? Process 20493 detached
I tried doing pidof powersaved at this point and it resulted in nothing. So, I guess powersaved is no longer running. I also got a little warning from kpowersave telling me to restart rcpowersaved. I did rcpowersaved restart and everything is back working as expected (CPU frequency is getting throttled as seen in /proc/cpuinfo for example).
maybe i get the picture. What we do after resume is: - fork, then execute "powersave_proxy global.resume.standby" to clean up. - i believe, now the parent process dies for some reason, so the only powersaved left is the forked child which executed powersave_proxy. - if powersave_proxy exits, the forked child exits (as it should) and no powersaved is running anymore. The question is: why is powersaved dying? Maybe it dies as a result of the socket connection or even before it (maybe the forked child inherits the socket, so the socket can still be connected but the connection is not handled by the child and so all powersave -c simply hang. If there is no socket, powersave -c should exit immediately). I cannot answer this, but i will ask the relevant person ;-)
Sorry if this was too much information.
No it wasnt, it was helpful for debugging the problem, even if it is not solved yet. MAYBE a very dirty hack to workaround this would be to replace the "$POWERSAVE_BIN -c" statement with a "/usr/sbin/rcpowersaved restart", it is still not a clean solution but it may work for you. -- Stefan Seyfried
On Sat, 4 Sep 2004 20:49:08 +0200, Stefan Seyfried
you can try to remove the "$POWERSAVE_BIN -c" statement from /usr/sbin/powersave_proxy in the resume_after_standby function, (it is on line 779 in my version, but this may be an edited one) but to be honest, i think this is just a symptom and not the cause.
I removed the "$POWERSAVE_BIN -c" statement (it was on line 779 in my version as well) from /usr/sbin/powersave_proxy. Now, when the laptop resumes from standby: if I do pidof powersaved I get nothing. So, it seems powersaved is no longer running. So, *maybe* the $POWERSAVE_BIN -c was actually causing a new powersaved to spawn?? Next, I replaced the "$POWERSAVE_BIN -c" with "/usr/sbin/rcpowersaved restart". Now, after resuming from standby, doing pidof powersaved still returns nothing. I put a DEBUG "rcpowersaved restarted" INFO to make sure that statement completely executed. And, I did see "rcpowersaved restarted" in /var/log/messages. But I still get no PID with pidof powersaved. Thanks for your help and let me know if you would like me to do more experiments. Osho
On Sat, Sep 04, 2004 at 01:51:14PM -0700, Osho GG wrote:
On Sat, 4 Sep 2004 20:49:08 +0200, Stefan Seyfried
wrote: you can try to remove the "$POWERSAVE_BIN -c" statement from /usr/sbin/powersave_proxy in the resume_after_standby function, (it is on line 779 in my version, but this may be an edited one) but to be honest, i think this is just a symptom and not the cause.
I removed the "$POWERSAVE_BIN -c" statement (it was on line 779 in my version as well) from /usr/sbin/powersave_proxy. Now, when the laptop resumes from standby: if I do pidof powersaved I get nothing. So, it seems powersaved is no longer running. So, *maybe* the $POWERSAVE_BIN -c was actually causing a new powersaved to spawn??
no, this was to work around an ancient bug when the powersaved would hang (but not crash) after a suspend to disk and cpufreq etc would no longer work until it got "kicked" by a socket connection. I don't know if it is still necessary but you know, such old cruft never gets thrown out again ;-)
Next, I replaced the "$POWERSAVE_BIN -c" with "/usr/sbin/rcpowersaved restart". Now, after resuming from standby, doing pidof powersaved still returns nothing. I put a
DEBUG "rcpowersaved restarted" INFO
to make sure that statement completely executed. And, I did see "rcpowersaved restarted" in /var/log/messages. But I still get no PID with pidof powersaved.
Well. There is probably some race: the old powersaved is still a running (although it will die soon), the socket is still in use and the new powersaved cannot be started because of this. I am now just shooting in the dark for a workaround until we find and fix the original bug. Try this: pushd /tmp nohup bash -c "sleep 5; /usr/sbin/rcpowersaved restart" & popd instead of the "rcpowersaved restart". This sleeps for 5 seconds (hopefully all powersaved instances have died then) and starts a new one after that. Don't forget the "&" to put the nohup statement into the background so that the powersave_proxy will finish and the powersaved child will terminate before we start a new one. You will find the output of this powersaved restart in /tmp/nohup.out. Good Luck ;-) -- Stefan Seyfried
On Sun, 5 Sep 2004 01:29:56 +0200, Stefan Seyfried
On Sat, Sep 04, 2004 at 01:51:14PM -0700, Osho GG wrote:
Next, I replaced the "$POWERSAVE_BIN -c" with "/usr/sbin/rcpowersaved restart". Now, after resuming from standby, doing pidof powersaved still returns nothing. I put a
DEBUG "rcpowersaved restarted" INFO
to make sure that statement completely executed. And, I did see "rcpowersaved restarted" in /var/log/messages. But I still get no PID with pidof powersaved.
Well. There is probably some race: the old powersaved is still a running (although it will die soon), the socket is still in use and the new powersaved cannot be started because of this. I am now just shooting in the dark for a workaround until we find and fix the original bug. Try this:
pushd /tmp nohup bash -c "sleep 5; /usr/sbin/rcpowersaved restart" & popd
The above worked perfectly ! rcpowersaved does restart powersaved. If I do pidof powersaved - a few seconds after resume - I do see that the new powersaved daemon started. Commands like 'powersave -c' or 'powersave -B" etc. work fine and return their expected result. This work around is perfect for me. Thank you very much. Nevertheless, I would love to continue experiments, if you like, so the actual bug can be root-caused and fixed. thanks, Osho
On Sat, Sep 04, 2004 at 06:35:51PM -0700, Osho GG wrote:
The above worked perfectly ! rcpowersaved does restart powersaved. If
Wonderful :-)
I do pidof powersaved - a few seconds after resume - I do see that the new powersaved daemon started. Commands like 'powersave -c' or 'powersave -B" etc. work fine and return their expected result.
Ok. Note that "powersave -B" accesses the battery files directly and will work even with a dead powersaved, but powersave -c is a good check if the daemon is still running (and the access permissions are right).
This work around is perfect for me. Thank you very much. Nevertheless,
It's really ugly, but it works at least ;-)
I would love to continue experiments, if you like, so the actual bug can be root-caused and fixed.
I'll talk to Thomas after the weekend, maybe the problem description triggers something for him, maybe the bug is even fixed in his code base. We have done a major rework of the powersave package for 9.2 including many improvements and possible bugfixes. The problem is, that due to the major changes in the internal structures, not everything is easily ported back to the 9.1 version ;-) I will try to write up some basic backup and upgrade instructions and put the package up on ftp.suse.com/pub/people/seife/powersave when i have done that. For now i am glad we found a workaround for you :-) -- Stefan Seyfried
participants (3)
-
Osho GG
-
Osho GG
-
Stefan Seyfried