[Pm-utils] [gpm] gnome-power-manger-2.26.0 suspend and hibernate

[Victor Lowther]

On Wed, 2009-03-25 at 19:03 +0000, Chris Vine wrote:
> All is now revealed.
> 
> I had made the mistake of thinking that /var/log/pm-suspend only
> contains what was also sent to stdout/stderr.  It doesn't, it reports
> also on how the hooks behave.

Handy, that.  :)

> /var/log/pm-suspend indicates that the problem was that the 55wicd hook
> was hanging on thawing.  I think this is a re-emergence of the fact
> that the reloading of the wireless modules also tries to bring up the
> wireless interface via udev and wicd could not handle two such requests
> at the same time.  udev always has to get there first because the
> modules have to be loaded before any calls are made to wicd.

In that case, would you mind trying the following patch on 75modules
with an unmodified 55wicd?

BEGIN PATCH
diff --git a/sleep.d/75modules b/sleep.d/75modules
index 3f292e4..ed8bbcf 100755
--- a/sleep.d/75modules
+++ b/sleep.d/75modules
@@ -15,6 +15,7 @@ suspend_modules()
 resume_modules()
 {
        modreload
+       udevadm settle --timeout=5
 }
 
 case "$1" in
END PATCH

> Simply commenting out the attempt to bring back the wireless interface
> in 55wicd when thawing/resuming solves the problem.  The reloading of
> the wireless modules will bring up the interface by itself (via udev).

The above patch should wait up to 5 seconds for udev to settle after
reloading modules.  Can you see if that allows an unmodified 55wicd to
work properly?

> With that change, all now seems to work happily.  Quite why 55wicd only
> hung on the first hibernate/thaw cycle in any user session is not clear
> but I guess that's hardware for you.

Indeed.  If hardware always worked the way it should this whole power
management thing would be much easier. :)

> Thanks for the help.

No problem.

> Chris
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019