These notes will favor Debian, although they are probably useful to any distro. The first part of this has little to do with the APM or ACPI capabilities of your machine. Instead, I will first discuss how to turn off your monitor and spin down your hard drive. In these states the machine itself is still completely "alive" and crunching numbers.

The power management features that control your CPU and motherboard, however, are governed by either the newer ACPI standard or the older APM standard. If you don't know what the difference between APM and ACPI is, do some research. Basically, ACPI allows the operating system to control most of the power-saving features of your box, whereas APM relies on the BIOS to control such features.

Linux has only started REALLY supporting ACPI in kernel 2.6 (and above, presumably).

The first line of business for ACPI/APM is to "slow down" your CPU whenever it is idle/inactive. This is important since the CPU is a HUGE power drain in your system, and it also creates a lot of heat which can damage the chip. In these different CPU states the machine is still completely alive and ready to crunch numbers at the drop of a hat.

The more aggressive power-saving features of ACPI/APM are what you might associate with Standby/Suspend/Hibernate or Standby/Suspend to RAM/Suspend to Disk states (the terminology seems to vary widely). In these states the CPU is completely shut down and much of the motherboard is dead as well. In the most extreme case (Hibernate/Suspend to Disk) even the RAM is shut down (and the contents are written to a file on disk). Obviously in these states the machine is in a "coma" and must be awaken to perform any tasks.

Turn off your MONITOR!!
Probably the biggest drain of power in your system is that giant screen sitting on your desk. Obviously, the best thing is to turn it off when you know that you will be leaving for a while.

Of course, most people forget this and the monitor drains energy for hours at a time. Note that so-called "screensavers" DON'T SAVE ANY ENERGY AT ALL. Even "blank" screensavers don't save even a watt. Throw those screensavers out - they're just a scam.

You really need to take advantage of the energy-saving features of your monitor and video card. These standards are entitled "Energy Star", and are very effective. There are generally 3 modes: Standby, Suspend, and Off. The Standby saves only a small amount of power, maybe only 10%. The Suspend mode is FAR more aggressive - usually like 80%. Finally, Off mode saves probably >95% of the power. The difference between the three has to do with the details of certain components in the monitor which are turned off. Obviously, the more aggressive power savings features require slightly more time to turn back on, but they are worth it.

Personally, I haven't noticed a difference in power-on latency time between "Standby" and "Suspend", so "Suspend" is preferred over "Standby" since it saves FAR more energy. I have my monitor settings at two levels. I have found that the monitor should go into "Suspend" mode after about 7 minutes of inactivity, and then it should go into "Off" mode after 10 minutes.

That being said, many monitors seem to mix up what the difference between "Standby" and "Suspend" is, so I just set them BOTH to 7 minutes, and I set "Off" to 10 minutes.

Instructions for simple window managers like FVWM
If you are using just a simple window manager like "fvwm" (not KDE, GNOME, or even XFCE4) then you need to change the settings in your "XF86Config-4" file (assuming you are using XFree86 4, otherwise it is called XF86Config). So you need to edit

/etc/X11/XF86Config-4

In the "ServerLayout" section you need to add the lines

Option "StandbyTime" "7"
Option "SuspendTime" "7"
Option "OffTime" "10"

In the "Monitor" section add the line

Option "DPMS"

Now, if you have an NVIDIA video card and you are using the "nvidia" driver (which is non-free written by NVIDIA), then there seems to be a bug where the monitor JUST WON'T GO OFF. To fix this bug, you need to add the same line to the "Device" section as well. Please ALSO note that for the "nvidia" driver the line I told you to add in the "Monitor" section (Option "DPMS")

ACTUALLY reads

Option "DPMS" "true"

(so it has an extra "true" tacked on the end). I don't know if the extra "true" is necessary.

Probably a better way to get around this is to use the open source driver "nv" for NVIDIA cards. There's something that bothers me about supporting and using proprietary junk anyway.

Instructions for KDE and XFCE4
In KDE the environment itself actually handles the power saving features of the monitor. Anything that you put in XF86Config-4 will be ignored (caveat: see the NVIDIA loophole above - this is still necessary. In fact, I'd make the above changes to XF86Config-4 just in case... it doesn't hurt, anyway).

In KDE go into "Control Panel->Peripherals->Display->Power Control" and make your settings there. The settings will take effect for each user independently (so it must be configured separately for each user).

In XFCE4 right-click and go to "Screen->Save->Screensaver Properties". Make sure that the screensaver is NOT disabled (I just set it to "Blank Screen". The XFCE4 screensaver is actually a daemon which also controls the power features of the monitor). In the "Advanced" tab you will see where to enable your powersaving features.

How much power are you going to save?
This is going to vary widely, obviously. I couldn't find the power documentation for my specific monitor, so here is a typical example of power consumption for a 17" monitor:

On: 120 Watts
Standby: 110 Watts
Suspend: 15 Watts
Off: 5 Watts

It is VERY clear that going into Suspend/Off mode is very effective.

Spin down those HARD DRIVES

BEFORE WE BEGIN: I'm uncertain how much of the following applies to SATA drives (or SCSI drives, for that matter). It is not possible to spin down the drives using hdparm. I believe SATA drives handle their own spindown features - still it is useful to know how to keep the kernel/daemons from accessing the drive (see below).

Furthermore, these tips work well for EXTRA disks on your system, but if your goal is to get the main drive (root partition plus swap partition) to spin down then you have your work cut out for you (see below)! The kernel (plus friends) are hungry drive-accessing beasts.

Let me clarify that I'm not a huge proponent of spinning down the drive TOO often (i.e. laptop mode). This is why I set my drive spindown time to 10 minutes. Basically, if I'm not doing anything for 10 minutes, then there's a good chance that I probably won't be accessing the drive for a couple of hours (I probably walked away and forgot the thing). To each his own.

HDPARM
IMPORTANT NOTE! I have encountered problems with using "hdparm" as described below with some hard drives. In particular, the spindown time doesn't seem to work for 2 out of 3 of my drives (shrug). Hence, I have started using a daemon called "noflushd" - see below for details. Also note that another utility called CPUDYN integrates hard drive spindown into its package. Still, some of the information found here is relevant.

The utility "hdparm" (only accessible as root) is your friend and enemy when it comes to (IDE) hard drives. This allows you to test the performance of your drives (see the "Performance" article on this site), modify the settings, and in general destroy your hard disk.

It also allows you to power your hard drives down after, say, 30 minutes of inactivity (I actually set mine to 10 minutes of inactivity, but whatever you can stand. It's slightly annoying when the hard drive is shut down and you need to wait for it to spin up to access something).

The settings are automatically determined at boot time by the configuration file /etc/hdparm.conf. Each device has a little section with all of the relevant parameters. The "spindown_time" is the important one here. In my file I have the lines

/dev/hda {
spindown_time = 120
...
}

where the "..." are other options which are not important here. The timing units are measured in intervals of 5 seconds, so a spindown_time of 120 is just 120*5 seconds = 600 seconds = 10 minutes.
important note: the 5-second intervals only apply up to 20 minutes, at which point the intervals increase. See the manpages for hdparm for an exact description of the time intervals.

Some people prefer to also put an "apm=[1-255]" line in there which corresponds to the hdparm command "hdparm -B[1-255]". However, I have found that this option actually disables my hard drives from spinning down, so I definitely leave this out! I have yet to find a decent bit of documentation on this option.

Just add one of these sections for each one of your physical drives (hdb, hdc, hdd, etc) and you should be *almost* ready to save some power (and life of those hard drives) - read on!

How to stop Linux from accessing the drive needlessly
Of course, this scheme only works if a drive stays idle for a certain period of time. This is actually trickier than it sounds since the kernel loves to always access the drive.

First, some filesystems (especially journalling filesystems) keep around not only creation and modification times for a file, but they log so-called "access times" for a file. This means that anytime you read a file its access time is updated. This seems like pointless information (in my mind), so I prefer to mount every filesystem with the option "noatime" like in the following example entry in /etc/fstab:

/dev/hdd1 /mount_directory reiserfs rw,noatime 0 0

You MUST use "noatime" - otherwise your filesystem will be accessed every 5 seconds, and NONE OF THIS WILL WORK!!!

That was the EASY part that applies to all drives. For those die-hard power-geeks who want to spin down their root drive, I can only give some feeble tips. Frankly I recommend just forgetting the root drive. It can be a real pain to track down each daemon and stop the stream of junk. First - turn off unnecessary logging. Have a look here for details concerning how to cut down on the proliferation of junk streaming from syslogd/klogd and cron. Each time one of these sends you a message, it wakes up the hard drive (and most of the time these messages are strictly routine).

sysklogd: In addition to the tips given in the above article about sysklogd/klogd, here's something that kept me tripped up for a short time. I noticed that every 20 minutes (or so) I would get a message like this:

Aug 20 05:55:19 localhost -- MARK --

SYSLOGD=""

SYSLOGD="-m 0"

Swap partition: you may have to give up your swap partition. I've noticed that, even without any system activity, some computers seem to page memory blocks in and out of swap for no apparent reason. I have plenty of RAM, so I just comment out the swap entry in "/etc/fstab" if this becomes a problem. UPDATE: Johnny Healey pointed out to me that the swappiness can be calmed down by using the command "echo -n 0 > /proc/sys/vm/swappiness". To have this done automatically at startup, add a line to /etc/sysctl.conf that reads "vm/swappiness=0". Thanks Johnny!

cron: David Edwards pointed out to me that cron has an hourly tasklist located in

/etc/cron.hourly

ntpd: David is full of good tips. I didn't realize that ntpd writes out drift information every hour to the file

/var/lib/ntp/ntp.drift

Furthermore, David modified his startup/shutdown script "/etc/init.d/ntp" to copy the driftfile FROM /var/lib/ntp/ntp.drift to /tmp/ntp.drift when the system starts and then copy it back when the system shuts down - all just to keep the driftfile around between reboots.

If you're feeling lazy (says David - hehe) then you can just forget ntpd altogether and instead run "ntpdate" every couple of hours (I run mine once per day from a script in "/etc/cron.daily"). This should eliminate your need to use "ntpd" - see my NTP page for more information.

Also, be aware that ntpd reports statistics in the directory

/var/log/ntpstats

statsdir /var/log/ntpstats/

smartd: Brian DeRosa recently pointed out to me the "smartd" daemon - which comes installed and enabled on Fedora systems these days. This beast will wake your drives every 30 minutes performing routine checks. Brian changed the checking frequency to once per week. Good tip.

David Edwards has pointed out that smartd can INSTEAD be configured to skip the check when the drive is spun-down by adding the option

-n standby,q

exim4: If you have an email server then you really shouldn't be trying to power down the root drive. If not, then why bother having exim4 installed? Probably because Debian installs it by default! You could just uninstall it. I instead just decided to disable it by running the command

update-rc.d -f exim4 remove

cupsys: Still causing me problems. I'll have to get back to you. So far cupsys and drive spindowns are not playing well together on my machine.

dhclient: If you are receiving your IP address from dhcp then you're in trouble. Not only does dhclient stream info to /var/log/daemon.log and /var/log/syslog, this seems hard-coded into the utility! Furthermore, halfway through your lease time (usually 3600 seconds) the file /var/lib/dhcp/dhclient.leases will be updated with a new lease (consequently waking up your hard disk). If anybody knows how to fix this stuff then please let me know!

NOFLUSHD
update: version 2.7.5-4 seems to be broken. I am successfully using version 2.7.5-2 right now. Again, if you only have a single drive, then I wouldn't recommend bothering with this. It's difficult to get a proper spindown, and noflushd will make your laptop CLICK CLICK CLICK fairly often.
Actually, I have encountered a fair number of problems while using the hdparm utility to set the spindown time. This is where the utility "noflushd" comes in as a replacement. If you are using Debian then you can just "apt-get install noflushd".

The daemon "noflushd" is more sophisticated than just a simple spindown utility. This daemon also restricts the kernel from flushing its "dirty" disk buffers too often (which would spin the hard drive back up).

The important configuration parameters (at least for Debian) are located in the file "/etc/default/noflushd" - these are rather self-explanatory.

Important note: you still need to mount your drives with journalling filesystems using the "noatime" option, and you will also need to cut down on the syslogd/klogd and cron activity on your machine - see above in the "hdparm" section.

More aggressive technique (for kernel 2.6): LAPTOP MODE
This article has some interesting ideas about putting your system into so-called "laptop_mode". I will definitely need to do some more research concerning this.

How much power are you going to save?
Most hard drives have somewhat similar power consumption characteristics. The following data is for a Western Digital 20GB EIDE drive at 7200 RPM:

Reading/Writing: 10 Watts
Idle (but spinning): 7 Watts
Not spinning (what we did above): 0.8 Watts
Spinning back up (takes about 6 seconds): 27.5 Watts
Sleep (not described - computer must be restarted): 0.4 Watts

You can see that by spinning down the drive you will save over 6 Watts. A little goes a long way over time, however. Also notice that the drive does consume almost 30 Watts while spinning back up. Even with this "tax" factored in you will save energy as long as the drive is down for more than 20 seconds (which it probably will be).

APM

The APM interface is an older standard that allows the BIOS to control the energy features of your CPU and motherboard. I won't describe it in gory detail here. Good references can be found here and here.

Note that you are stuck with APM if you are using Linux kernel 2.4 or below. There ARE claims that some of the patches for kernel 2.4 support ACPI, but I could never get them to work (and I recompiled my kernel about 20 times, eating up far more energy than I would have probably ever saved). On the other hand, I should clarify that I still use APM on my laptop. ACPI still seems pretty buggy, actually (as of kernel 2.6.10 at least) when it comes to being able to suspend/hibernate the machine (see below).

There are 3 energy states associated with APM (besides being "fully active", of course). In order of increasing energy savings they are:

Standby - least energy savings; CPU is shut down
Suspend (Suspend to RAM) - Huge energy savings - everything is shut down except the RAM
Hibernate (Suspend to Disk) - Full energy savings - the RAM contents are written to the hard drive and then even the RAM is shut down.

The ones that are *readily* available with the APM system are Standby and Suspend to RAM. I prefer Suspend to RAM since the energy savings are A LOT more (if the computer is going to become inactive, it should be REALLY inactive - note that each 512MB of DDR memory still consumes about 5 Watts). Hibernate functionality is considerably more difficult. This actually requires using a completely separate project (independent of APM or ACPI) called Software Suspend 2 (SWSUSP). Note that this project requires patching and recompiling the kernel. UPDATE: SWSUSP2 has been replaced with a user-space utility USWSUSP. It seems to work more reliably than SWSUSP2, but not on all machines - see below in the ACPI section. Unfortunately, these patches JUST DON'T WORK for Debian kernels (at least no 2.4 or 2.6 kernels worked)! You must use a plain vanilla kernel in order to use Software Suspend 2 (at least it seems). See below in the ACPI section for further commentary. I have had only marginal success with hibernate.

Nevertheless, using either the Standby or Suspend mode is rather straightforward in Linux.

First, to use APM, you will need to compile "APM Support" into your kernel. Since this is already done (in Debian at least, and probably in most stock kernels) I won't describe how to do that. Consult this reference if you are unsure.

You need to also add the "apm=on acpi=off" options to your kernel boot options. Obviously, this turns APM on and turns ACPI off (the two are NOT compatible). For example, I am using grub as a bootloader (you might be using LILO), so in my "/boot/grub/menu.lst" file I have the following line (yours will vary):

kernel /vmlinuz root=/dev/hda4 ro apm=on acpi=off

It should be clear that you will need to reboot your machine to have the kernel use APM.

Important UPDATE: I have had a problem with kernels (2.6.x) which have both ACPI and APM compiled in (as modules or whatever). Even with the command-line options as above, APM would mysteriously just STOP working (and never reload). I have NO idea why this is - I had APM working perfectly, and then after a couple of reboots the module was not installing at bootup. Running "apm" I would get the error message "APM not supported in kernel". To remedy this, I had to recompile my kernel with ACPI taken completely out and APM put in (compile APM directly into the kernel - there's no reason to use a module for this). Furthermore, you might be tempted (when recompiling) to use all of the extra APM options which are included. Since there is little/no explanation of these options you will probably think that they are extra features. In fact, these are WORKAROUNDS for BIOSes that don't work exactly right. For example, I tried the option CONFIG_APM_CPU_IDLE which made my CPU screech with a high-pitched buzz whenever it was idle. Chef doesn't recommend.

Next, you will need to install the APM daemon "apmd" and the related APM utilities. In Debian, all that I had to do was install the package "apmd". The important (for you, at least) utility is called apm. This utility interfaces with the APM daemon apmd which controls the show.

To send the system into Standby mode, just use the command "apm -S". To be even more aggressive and use Suspend mode, use the command "apm -s". You can allow normal users to run these programs by allowing sudo access (see, for example, my shutdown article for a sudo example).

How to make this all automatic: SLEEPD
Often you might want to configure the computer to "sleep" after there have been no keystrokes/mouse movements for a certain number of minutes. This can be done by using a daemon called sleepd. As usual, in Debian just install the package "sleepd".

The man page documenting sleepd is pretty self-explanatory (however note that the "-U" option doesn't seem to work... just use "-u"). As usual with any daemon (in Debian, at least) the configuration file that configures sleepd is located at "/etc/default/sleepd". By default sleepd waits for 10 minutes (more precisely, 600 seconds) and then runs "apm -s" which suspends the computer. These options can be changed in this file. For example here is my "/etc/default/sleepd" file:

# PSYCH!!!  pm-suspend.custom is my own script
# and it applies to ACPI... sorry folks
PARAMS="-u 600 -s /usr/bin/pm-suspend.custom"

/etc/init.d/sleepd restart

It also pays to sometimes be able to temporarily stop sleepd. Maybe you are running a model, or downloading something big, or something else which requires the computer to stay on. Since "sleepd" considers the computer to be idle unless it receives interrupts (generated by, say, keystrokes or mouse movements), your computer will suspend if you leave it. The relevant command is called sleepctl. To disable sleepd, just type "sleepctl off". To enable it again, type "sleepctl on". Check the manpage for "sleepctl" since it explains that disabling sleepd using sleepctl is a cumulative command (meaning sleepd can be disabled twice, three times, etc... and it won't start until the number of disables is zero).

ACPI

UPDATE: I don't have time to revise this howto now in depth, but the standby/suspend to ram/suspend to disk features of ACPI are better controlled now with modern packages such as "pm-utils" (the latest), "powersaved" (good, but being replaced), "hibernate", or Ubuntu's "acpi-support". You will probably have to experiment with these 4 alternatives. There are graphical managers called "kpowersave" (for KDE - once relied on "powersaved" but is now *kind of* independent) and "gnome-power-manager" (I've never used it). I use "kpowersave"+"powersaved" on my laptop, but it doesn't work on my main machine (so I use "pm-utils"+"cpufrequtils" for that - see below).

Please see the following website for official documentation about ACPI. As above for APM (except vica versa), you will need to add the line

kernel /vmlinuz root=/dev/hda4 ro apm=off acpi=on

to you /boot/grub/menu.lst (assuming you are using the bootloader grub).

CPU "C states" ("power management")
Many aspect of power management are described beautifully here. Basically, there is probably nothing that you have to worry about concerning the CPU "C states". These are automatically controlled by the kernel+ACPI system taking into consideration current system load. (CAVEAT: check out the note about AMD Athlon and Duron processors below). The ACPI code in the newer (2.6+) kernels automatically puts your CPU to sleep when there is idle time (note: this does not change the CPU frequency. That is controlled by "P states" - see below).

The only thing to realize is that your system is completely "conscious" when the CPU is momentarily halted - you won't notice much of a difference. However, the power savings can be considerable. Just think of it as having your CPU taking thousands of "micro-naps" whenever it is idle.

Special for AMD Athlon and Duron processors
Important: in the paragraphs below I describe the use of the "athcool" utility to enable special powersaving for AMD Athlon and Duron processors. This worked VERY well for about six months, then my computer became unstable. It would periodically power down, freeze, etc. After replacing several components (and getting a good power supply) I found that the culprit was "athcool" - be warned that this program can cause instability and frequent power failures. My motherboard has a VIA VT8366/A/7 KT266 chipset.

Unfortunately, the usual HLT (halt) command that the kernel uses for sleeping doesn't seem to give large power savings for certain AMD processors (see this article). Instead, a separate command STPGRNT (Stop/Grant) must be issued in its place. To have the CPU use this power state instead for your CPU, you will need to use a utility called athcool. I installed it by just installing the Debian package "athcool".

In order to enable this STPGRNT manually, you can run (as root) the command "athtool on". The command "athtool stat" will tell you if the Stop/Grant state is currently honored. In *theory* athcool should be rerun automatically when the computer reboots. Indeed, I noticed that there is an "athcool" script in "/etc/init.d/" which is where Linux keeps its startup scripts. Unfortunately there is no symbolic link to this script in the /etc/rcS.d/ or in the /etc/rc2.d directories, which is where Debian actually *looks* for startup scripts. I think this is a bug in athcool, so I just put the line

/etc/init.d/athcool start

into the file "/etc/init.d/bootmisc.sh" since this is a startup file which runs miscellaneous commands.

It is worth pointing out that my idle CPU operating temperature dropped from about 65 Celsius to about 38 Celsius after I installed this program. That should give you a good idea how effective this is at saving power AND saving your CPU!!!

CPU "T states" ("throttling")
Now we want to consider so-called "CPU throttling" or T states. Again, please read this reference. These are very much like "C states" (the same HLT instruction is used), however the difference is that throttling is "forced by you" (like every 4th cycle is forced to be a sleep cycle, as opposed to the "C states" above which are automatically determined by the system load). Note that the frequency has NOT been changed... see the "P states" below.

If your CPU supports "P states" then you should probably just use those (they are supposedly more efficient anyway). If not then you can access the T states by setting them manually as described in the article mentioned above. I don't know if there is a daemon to automate the task (there probably is).

CPU "P states" ("performance management")
Again, please read this reference. P states are the preferred method for saving processor power. Many processors these days (especially laptops) can have the clock frequency actually slowed "on the fly". This adds up to huge power savings. Intel calls this "SpeedStep" and AMD calls it "Cool'n'Quiet" or "PowerNow". More generically these states are called "P states". You will almost certainly have to go into the BIOS and enable this feature for your CPU FIRST!

There are a couple of utilities that can adjust the P states automatically depending on system load. For example, the "powernowd" daemon works, as well as "powersaved" (which controls much more).

I like the CPUFreq utilities (used in conjunction with "pm-utils" described below). Just install the package

cpufrequtils

modprobe powernow-k8

modprobe cpufreq_ondemand
modprobe cpufreq_powersave

cpufreq-info

cpufreq-set -g ondemand

cpufreq-set -g powersave

What are the power savings from the above CPU states?
The following data is extracted from the AMD website. Consider an AMD 64 3400+/2200MHz with 1 MB of L2 cache. By the way, while I'm here, let me complain about the AMD naming convention. The number 3400+ doesn't mean jack squat. This is just AMD's way of saying that this processor "looks like" an Intel Pentium-4 running at 3400MHz. I guess this is their way of not losing marketshare. Here are the P and T state power consumption values (the C state is the same HLT instruction as the T state):

Performance State 0 (Fully Active) (2200MHz): 89 Watts
Performance State 1 (2000MHz): 70 Watts
Performance State 2 (800MHz): 35 Watts
Throttled (HLT instruction): 2.2 Watts

It is worth pointing out that throttling is a bit "out of style" in favor of the better savings provided by the "P states".

Shutting down ALMOST everything: Sleep States
These are the power-saving features that actually put your computer into a coma. If you are just a regular user, then you will want to use these features. On the other hand, if your computer is CONSTANTLY performing tasks (downloading, crunching models, whatever) then you will probably not have much use for so-called S-States. I should mention that I have personally had only varying degrees of success with these states. Sometimes the state doesn't work, or the computer reboots in an unstable state, or whatever. On the other hand, it is embarrassing for any user of any normal home computer to NOT use these features.

Just like in APM, there are 3 states - all of which are modelled on the APM scheme. These states are called "standby" (obviously corresponding to Standby in APM), "mem" (corresponding to Suspend="Suspend to RAM" in APM), and "disk" (corresponding to Hibernate="Suspend to Disk" in APM).

Manual method (probably won't work)
As in APM, the first two are rather easy to do, but this method almost certainly won't work (again, mem=suspend saves much more energy than standby). For 2.6 kernel, there is a file in "/sys/power/" called "state". This isn't a real file (in the classical sense), but rather a way of "talking" to the kernel. If you want to send the computer into standby (mem and disk are similar) then just issue the command

echo -n standby > /sys/power/state

Important note!!! My computer does not respond to the "standby" state given above at all, and it does not return successfully from the "mem" state. The "disk" state requires the Software Suspend 2 package below.

PM-Utils method
There are a variety of scripts that stand a better chance of giving you a working suspend to RAM ("pm-utils", "powersaved", "hibernate", or "acpi-support". Also there are some gui's that MIGHT work flawlessly for you: "kpowersave" and "gnome-power-manager"). Again I will discuss "suspend to disk" a bit below, although I still find it unusable.

Let's discuss "pm-utils". After installing the package you can try to "Suspend to RAM" using the command (as root)

pm-suspend

#!/bin/sh

/sbin/rmmod forcedeth
/usr/sbin/pm-suspend
sleep 2
/sbin/modprobe forcedeth
/sbin/rmmod forcedeth
/sbin/modprobe forcedeth
/etc/init.d/networking restart

Suspend to Disk (Hibernation) using SWSUSP
UPDATE: replaced by userspace program USWSUSP - see below. Software Suspend 2 has also had its name changed to TuxOnIce. The Software Suspend 2 project allows you to make full use of the "Suspend to Disk" or "Hibernation" functionality of your machine. So far I have had only marginal success with this project.

Update: I have tried patching my kernel (now Debian 2.6.11) with SWSUSP, but none of the patches apply successfully (grrrrr). I'm giving up the project for now.

Double update: I retried the project using a plain vanilla kernel 2.6.11.7 from kernel.org. The patch applied without any problems (of course, the kernel itself did not even compile due to some crappy code which they included in the "Linux Video Multimedia" junk, but that's another story). However, the "hibernate" script just crashed my machine. After about 5 recompiles and a lot of headaches, I realized that it is BEST to just NOT USE INITRD with Software Suspend 2. There are instructions on the SWSUSP2 site for using the INITRD stuff, but they didn't work for me. In the end I just manually compiled IDE support and Reiserfs support into my kernel and junked "initrd" altogether. After that, SWSUSP worked fine - almost. The machine hibernates and resumes without problems from a text console. However, from X Windows the machine will resume with corrupted video. I was forced to CTRL-ALT-BACKSPACE and kill the corrupted X Windows. Without being able to resume X Windows I really don't see the point of hibernation, so I have given up the project again.

Suspend to Disk (Hibernation) with USWSUSP
I wish that I had time to write this up more clearly. However, my real job is the priority. This project seems to work better than TuxOnIce (SWSUSP2) usually, but not always (of course). First, make sure that suspend/hibernation support is compiled into your kernel. Check the web for details - it's a pretty obvious option if you configure your kernel with "make menuconfig" and look into the power management section.

Now just install the debian packages

uswsusp
initramfs-tools

You can suspend to disk with the command

s2disk

How to make this all automatic
*If* you manage to get any of these sleep/hibernate functions working right in ACPI then you will probably want to make the computer automatically sleep when idle (idle=no keystrokes,no mouse). As with APM you can use the sleepd daemon. UPDATE: if suspend in "kpowersave" works for you then you can use that instead for automatic sleeping. It's pretty self-explanatory there. I already outlined this program above in the APM section. Note that "sleepd" is by default configured to use APM. Hence, you will need to reconfigure which command it calls when the computer is idle for a certain period of time. For ACPI perhaps you will configure it to call "pm-suspend" for example. See above for more details.

Automatic wakeup with RTC timers - great for backup servers
Special edition! Coming soon. I love this... Reminder to self:

rmmod rtc
modprobe rtc-cmos

This page has been visited   times since March 2, 2005