Chris Vine wrote: > On Tue, 24 Mar 2009 21:35:11 -0500 > Victor Lowther <victor.lowt...@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 _______________________________________________ Pm-utils mailing list Pm-utils@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pm-utils
