[Pm-utils] Some thoughts about some of the hooks

[Stefan Seyfried]

On Tue, Oct 10, 2006 at 07:50:17PM -0400, Peter Jones wrote:
> On Thu, 2006-10-05 at 18:50 +0200, Stefan Seyfried wrote:
> > 05led:
> > - the kernel should actually do this when platform mode is used. It seems
> >   to behave strangely since some versions, though, so i will investigate
> >   this.
> 
> Eh?  Kernel really doesn't know we're doing suspend operations until
> *well* after it's useful to have the blinky lights.

Oh well, since we do not too much stuff in pm-utils anyway (unmounting
external drives will be done by the desktop, stopping services and removing
modules should not take that long), the longest period of time is spent
in my case in the "snapshotting system" phase. Which is already inside the
kernel (or s2disk, which i count as "kernel" and which recently got support
for pm_ops->prepare which should start the blinking of the LED).

OTOH it's surely no big issue. My toughbook has no blinking LED anyway ;-)

> 
> > 10NetworkManager
> > - 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?
> 
> No -- Using NM does not imply that you're using a graphical setup, which
> is generally where those session daemons come from.

But it is policy. I often suspend machines without shutting down the
network and it works just fine.
We have been told that policy does not belong into HAL and friends ;-)

> > 49bluetooth:
> > - 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.
> 
> This is basically a hack because the BT modules/daemons have spent so
> much time being completely hosed.  Every bug you can imagine has shown
> up in them at some point in time.  If distros think they have working
> support, they're certainly not compelled to use all of the scripts
> pm-utils provides.  They're just defaults.

Ok
> 
> > 50modules:
> > - 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.
> >   :-)
> 
> Generally modules have been broken for both if broken for either.  There
> might be some exception, but basically this is there to fix broken
> modules, so the real answer is to fix the modules and make this module
> list be empty. ;)

That's correct. And the (really annoying) r8169 problem is already fixed.
If somebody really needs something like that, he can always drop an extra hook
to unload his very-special-broken-module.ko
 
> > 90clock:
> > - 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).
> > - just waiting 20 seconds does not ensure that NetworkManager etc. has come
> >   back.
> 
> Yep, it's a racy kludge.  But ntpd sucks ass and can't deal with having
> no network sanely.

Still setting the hwclock after resume is a bad idea IMO since the kernel
already did that. And setting it before suspend is at least questionable,
especially if you do not have a permanent network connection.

> >   -> this should be done from a networkmanager-dispatcher-skript.
> 
> No, ntpd should just be fixed.

Yes, that would be the perfect world. But since the ntp guys probably don't
think that using ntp without a permanent network connection is a good idea,
i doubt they will fix it any time soon :-)

-- 
Stefan Seyfried                  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices      \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \                    -- Leonard Cohen