On Thu, Oct 05, 2006 at 09:45:55PM +0200, Tim Dijkstra wrote: > On Thu, 5 Oct 2006 18:50:00 +0200 > Stefan Seyfried <[EMAIL PROTECTED]> 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 * > > /sys/power/state' 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 even better. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
