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

[Victor Lowther]

Chris Vine wrote:
> On Tue, 24 Mar 2009 21:35:11 -0500
> Victor Lowther <victor.lowther at gmail.com> wrote:
>> Would you mind emailing the scripts to me so that I can see why they
>> are doing that pm-utils is not?
> 
> All it does is to unload the problematic modules and then call the
> kernel interface with 'echo disk > /sys/power/state'.   So it is
> completely trivial.
> 
> I have an acpi handler which deals with resumption.
> 
>>> Automatic module reloading is a useful feature but slightly
>>> problematic in this case.  There is a trickiness about reinstalling
>>> the wireless modules automatically as this triggers a new udev
>>> insert event which will cause the wireless interface to come back
>>> up, whilst wicd (my wireless management client) also has its own
>>> pm-utils resume handler. I therefore do it by hand in a way which
>>> doesn't worry wicd too much.
>> Hmmm... that sounds like udev is being overzealous on your distro.
>> What distro are you using?
> 
> Slackware 12.2, which comes with vanilla udev-135.  It isn't really
> problematic.
> 
>>>> Also, what is the HIBERNATE_MODE environment variable?
>>> It is unset, so the raw kernel interface should be invoked.  The raw
>>> kernel interface works fine with my laptop, provided I unload the
>>> wireless modules first.
>> The reason I asked is that pm-utils does not know about
>> HIBERNATE_MODE, and will always fall back to native kernel support if
>> nothing else (uswsusp, tuxonice) is installed.
> 
> That's not what the documentation says.  The man page refers to the
> configuration variable HIBERNATE_MODE, about which it says "Default
> method to power down the system when hibernating. If not set, the
> system will use the kernel default as a default value.
> Check /sys/power/disk for valid values. The default value will be
> surrounded by [square brackets]."
> 
> In addition logging with PM_DEBUG shows that pm-hibernate itself sets
> this environmental variable, in my case to 'kernel', which is correct.

Ah, forgot about that bit of functionality.  I should really rename that 
env var -- all it does is tell the kernel what powerdown method to use 
after saving the memory to whatever backing store is being used.

>> If you try PM_DEBUG=true pm-hibernate, does it log anything that way?
> 
> It doesn't log any errors but it has indirectly told me what the
> problem is, but not the cause.  Running pm-hibernate the first time by
> hand from the command line (rather than via gnome-power-manager) shows
> me that after thawing the process never finishes - it just hangs.  It
> doesn't log anything about this however. All the logging takes place at
> hibernation rather than at thawing.

Very interesting -- it does not log anything during thaw at all?  Could 
you post the last few lines that it does log to the list?

> If after thawing I call 'killall pm-hibernate' I can then hibernate
> again. What's more, having done this once in the initial
> hibernation/thawing cycle, I can then hibernate repeatedly afterwards
> without the need explicitly to kill the pm-hibernate process in
> question.

Yeah, we use a lockfile to ensure that only one suspend/hibernate is 
being processed at any given time.  Killing the process releases the 
lockfile.

> Weird.  Perhaps a hook at 00aaa.sh in /etc/pm/sleep.d which calls
> 'killall pm-hibernate' on thawing would do the trick?

Depends -- if I understand what is happening, pm-hibernate is never 
getting to the point that it would run that hook on thaw.  The debug 
output should make that clear, though.

> Chris