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