[Pm-utils] Some thoughts about some of the hooks
hughsient at gmail.com
Tue Oct 10 09:18:31 PDT 2006
On Thu, 2006-10-05 at 18:50 +0200, Stefan Seyfried wrote:
> while investigating pm-utils, i went through all the hooks that are in the
> default distribution. This is what i found:
> - 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.
> - we need to restore the original behaviour in case the suspend fails.
> - should not be in the pm-utils package but in the grub package.
> - the kernel should actually do this when platform mode is used. It seems
> to behave strangely since some versions, though, so i will investigate
Last time somebody checked this was still needed, hwo do you mean
> - should be in NM package
> - shouldn't the "session daemons" actually do this? Send a "going to suspend"
> signal which NM (and others) will listen to?
gnome-power-manager currently does this, but it NetworkManager doesn't
mind being asked twice.
> - 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).
> - what is this good for? It is much easier (and safer) to just virtually
> unplug the BT dongle before suspend (by rmmod'ing hci_usb) and replugging
> it after resume. I never had a single problem with that.
Yes, although the kernel should probably be fixed to "just work".
> - 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.
Yes, I keep getting emails about how to blacklist oddball modules, so
this has to stay :-)
> - setting the hwclock before suspend is only needed if your cmos clock runs
> badly wrong. If you do not have ntpd running (no network, notebook), then
> it might make things even worse. Resetting system time after resume from
> the cmos clock is not needed, the kernel does this already.
> (We had this option in powersaved since up to 2.6.7(?) the kernel did not
> do this correctly. After the kernel was fixed, we set the default to "off".
> I never had a bugreport about it ever since, so i wanted to remove it from
> powersaved anyway).
I know nothing about this one. Peter?
> - just waiting 20 seconds does not ensure that NetworkManager etc. has come
> -> this should be done from a networkmanager-dispatcher-skript.
> - if it stays, it should be in the ntpd package
> - see 05led :-)
> This is what i saw after a short look. There might be stuff that i simply
> don't understand, but before i start adding more stuff to the hooks directory,
> i want to know if i am on the right track :-)
You are, nice one.
More information about the Pm-utils