[Pm-utils] Some thoughts about some of the hooks
seife at suse.de
Thu Oct 5 22:56:11 PDT 2006
On Thu, Oct 05, 2006 at 09:45:55PM +0200, Tim Dijkstra wrote:
> On Thu, 5 Oct 2006 18:50:00 +0200
> Stefan Seyfried <seife at suse.de> wrote:
> > Hi,
> > while investigating pm-utils, i went through all the hooks that are
> > in the default distribution. This is what i found:
> I've been doing the same to see if I can include it into debian, and if
> it will play nice with uswsusp. So I just add some of my comments...
Ok. I am going to try to move all our powersaved scripts to pm-utils, and
making it work with uswsusp (which is our default now) would have been one
of the tasks anyway :-)
> > 01grub:
> > - should not be the first one that is called. If something fails and
> > we do not actually suspend, the user will have a surprise at the next
> > reboot.
> Won't the hooks be run in reverse order regardless?
Only on resume, during suspend they are run in the order of "ls -1".
I am not sure what happens if we actually abort a suspend due to, say, failure
of unmounting / ejecting external usb drives (we had this possibility in
powersaved to avoid data corruption). And 01grub does not restore the old
config after resume anyway
> > 20video:
> > - should be the last thing that is done before suspend, so it will be
> > the first thing that runs after resume. Otherwise users that switch
> > the console too might cause trouble.
> > This is one reason why s2ram has everything in one binary, to make
> > it less likely that somebody else messes around with the video
> > hardware. Still not perfect (it should be in the kernel), but we
> > might get it there with some help from the uswsusp infrastructure
> > (freeze everything but s2ram).
> Also 20video doesn't play nice with s2ram/s2both/s2disk. They will do
> vt switching and video reboot already. I think 20video should be a
> special case function, not one of many in the hooks dir.
> Else it's kind of hard to make s2* a drop in replacement for 'echo * >
Yes, i obviously agree :-) But otoh it does suspend/resume the video adapter
via HAL, so maybe we have to change it in HAL to only have hal suspend/resume
the video adapter on org.freedesktop.Hal.Device.VideoAdapterPM.ResumeVideo if
s2ram is not installed.
If s2ram is installed, HAL could just skip this step and later call s2ram
with the apropriate options from the machine's (fdi)-configfile.
> > - different lists of modules for suspend / hibernate might be a good
> > idea (yes, i had a machine with r8169 that needed to be unloaded
> > before suspend to RAM otherwise the machine would lock up hard, but
> > needed to stay during suspend to disk, otherwise the network was
> > dead. The driver is fixed now. :-)
> Are you planing to keep a modules blacklist in CVS also? If so it seems
> to be a good idea to only accept entries which also have an entry in
> the kernel bugzilla.
No, not really. I even think "button" in there is wrong, since we should
either fix the module to not emit a button/power event after resume or
userspace should remember the system state and ignore button events until
resume is finished (we did this in powersaved).
Checking it right now on a Toshiba Tecra 8200, i do not get a button/power
event after resume from suspend to ram (toshibas were notorious for doing
that) and i seem to remember that somebody posted a fix for this on the
acpi-devel list one or two kernel versions ago, so "button" may already
be superfluous in this list.
What i think we should have is a global "SLEEP_MODULES" list (default empty)
that applies to "suspend" and "hibernate" and additional a "SUSPEND_MODULES"
list that, if set, overrides "SLEEP_MODULES" for "suspend" and a
"HIBERNATE_MODULES" list likewise for "hibernate".
However, we could also achieve this with /etc/pm/suspend.config and
/etc/pm/hibernate.config which will simply be sourced (if present) after
/etc/pm/config and can override the settings from pm/config. Maybe this is
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."
More information about the Pm-utils