[gpm] FC5 troubles: how do acpi, pm-utils, and gnome-power-manager fit together?

["Paul Johnson" <pauljohn32 gmail com>]

I have a new Dell D820 Duo-Core Centrino and I've had a few surprises
in power management.  I'm using the Nvidia proprietary X driver
(because I need 3d for statistical models) and it is a nice laptop.
Compared to the D800, it is much better.  If no network drivers are
loaded and I am not using a second hard disk in the modular bay, then
suspend to RAM works "out of the box" on FC5, with no ACPI
event/actions files configured.  Also, the running-on-battery
automatic suspend to RAM works, and the system does wake up, video and all.

I believe that must mean that pm-suspend is being used to suspend the
laptop, either when I hit FN-Suspend or the suspend action is
triggered by Gnome.   Is that right?

On this particular video card (Quadro), I've not seen the same video
wakeup problems that I had on the Geforce card.  Once or twice the
screen  on the D820 stayed black after restarting, but I don't know if
that was a kernel lock or a video problem.  Since the video does wake
up sometimes, I think that means it is OK.  I've also noticed that
pm-utils provides the pm-suspend function, which provides the file
functions-nvidia, which assumes I'm using the video driver provided
with X.  The proprietary
Nvidia driver does not work well with vbetool commands, especially the
vbetool post command, so while bug-testing I commented that out in
functions-nvidia.  But the system did suspend and resume before I did
that, making me think it was an unnecessary change. (On the Dell D800,
the vbetool post command causes the X server to crash and the screen
is filled with a white/pink gradient as the system locks up).

If I put ACPI actions and events scripts in /etc/acpi, as I used to on
the Dell D800, I get a little more control over which things are
turned off before suspending.  I started doing this because sometimes
the system does not suspend or resume, and after a while I noticed
that the problems happen when certain kernel modules are loaded or
certain devices are attached.  For example, if the ipw3945 wireless
device is active, the system can suspend to RAM, but can't wake up. As
far as I can tell, it is necessary to make REALLY sure all ipw3945
components are killed or removed before suspend to RAM.

i can try to configure that in /etc/acpi/actions/sleep.sh and then the
FN-suspend key combination uses the ACPI script to suspend.  However,
I can't figure how to make gnome-power-manager use that script. GPM
seems always to want pm-suspend.  Yes?

On the D800, pm-hibernate worked without trouble, unlike suspend to
RAM, which was fraught with trouble (tough to remove all bad modules
and wake up video dependably).
On this system, if I run pm-hibernate, the system tries to turn off,
it writes on the disk a while, and then the screen goes dark but the
power does not turn off.  The power light stays on, but nothing
happens.  So there's something at the very last minute that fails in
the hibernation.

So maybe I should work on customizing some ACPI script for that?

ps.  While testing, I've added the kernel option agp=off and I've
turned on the Nvidia AGP support in xorg.conf.  That was vital on the
D800 and I just did it here after suspend troubles started to arise.

However, I GUESS that this change was not needed, because the system
does sometimes suspend & resume just fine (meaning the video module is
not a trouble-maker, right?)

Here's the ACPI script I've been using. It works as long as ipw3945 is
not turned on.


#!/bin/sh
#
# ACPI suspend to ram script
#
# http://www.kananov.com/notes/s3

#Modules to unload before suspend. This are known troublemakers!
MODULES="tg3 uhci_hcd ehci_hcd hci_usb ipw3945"

###if you use linuxant modem drivers you also need this
##MODULES="$MODULES hsfusbcd2 hsfmc97ali hsfmc97via hsfmc97ich
hsfpcibasic2 hsfserial hsfengine hsfosspec hsfsoar"



set -x

################################################## ########################
# HELPER FUNCTIONS
################################################## ########################

# function to remove modules
rmmodules () {

for mname in $MODULES ; do
if grep $mname /proc/modules ; then
rmmodule $mname
fi
done

}

# function to remove module and all dependant modeles via recursive calls
rmmodule() {
# module name
m=$1
# get list of dependant modules
dep_m=`lsmod | grep "^$m" | awk ' { print $4}'`
if [ "x$dep_m" != "x" ] ; then
for m1 in $dep_m ; do
rmmodule $m1
done
fi
rmmod $mname
echo modprobe $mname >> /var/run/acpi-resume-post
}


################################################## ########################
# MAIN PART
################################################## ########################


# source sleep config
#. /etc/sysconfig/acpi-sleep

# do not got to suspend mode if some command fails!
set -e

# sync software time to hw
hwclock --systohc

# remove problematic modules
rmmodules

# sync write cache
sync

# sleep
echo mem > /sys/power/state

# reinsert modules
if [ -f /var/run/acpi-resume-post ]; then
sh /var/run/acpi-resume-post &> /dev/null
rm -f /var/run/acpi-resume-post
fi

#
hwclock --hctosys

# restart HAL
service haldaemon restart



--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas