32.4 The powersave Package

The powersave package cares about all the previously-mentioned power saving functions. Due to the increasing demand for lower energy consumption in general, some of its features are also important on workstations and servers, such as suspend, standby, or CPU frequency scaling.

This package contains all power management features of your computer. It supports hardware using ACPI, IDE hard disks, and PowerNow! or SpeedStep technologies. The functions from the packages apmd, acpid, ospmd, and cpufreqd (now cpuspeed) have been consolidated in the powersave package. Daemons from these packages, except acpid that acts as a multiplexer for ACPI events, should not be run concurrently with the powersave daemon.

Even if your system does not contain all the hardware elements listed above, use the powersave daemon for controlling the power saving function. Because ACPI and APM are mutually exclusive, you can only use one of these systems on your computer. The daemon automatically detects any changes in the hardware configuration.

32.4.1 Configuring the powersave Package

The configuration of powersave is distributed to several files. Every configuration option listed there contains additional documentation about its functionality.

/etc/sysconfig/powersave/common

This file contains general settings for the powersave daemon. For example, the amount of debug messages in /var/log/messages can be increased by increasing the value of the variable DEBUG.

/etc/sysconfig/powersave/events

The powersave daemon needs this file for processing system events. An event can be assigned external actions or actions performed by the daemon itself. For external actions, the daemon tries to run an executable file (usually a Bash script) in /usr/lib/powersave/scripts/. Predefined internal actions are:

  • ignore

  • throttle

  • dethrottle

  • suspend_to_disk

  • suspend_to_ram

  • standby

  • notify

  • screen_saver

  • reread_cpu_capabilities

throttle slows down the processor by the value defined in MAX_THROTTLING. This value depends on the current scheme. dethrottle sets the processor to full performance. suspend_to_disk, suspend_to_ram, and standby trigger the system event for a sleep mode. These three actions are generally responsible for triggering the sleep mode, but they should always be associated with specific system events.

The directory /usr/lib/powersave/scripts contains scripts for processing events:

switch_vt

Useful if the screen is displaced after a suspend or standby.

wm_logout

Saves the settings and logs out from GNOME, KDE, or other window managers.

wm_shutdown

Saves the GNOME or KDE settings and shuts down the system.

If, for example, the variable EVENT_GLOBAL_SUSPEND2DISK="prepare_suspend_to_disk do_suspend_to_disk" is set, the two scripts or actions are processed in the specified order as soon as the user gives powersaved the command for the sleep mode suspend to disk. The daemon runs the external script /usr/lib/powersave/scripts/prepare_suspend_to_disk. After this script has been processed successfully, the daemon runs the internal action do_suspend_to_disk and sets the computer to the sleep mode after the script has unloaded critical modules and stopped services.

The actions for the event of a sleep button could be modified as in EVENT_BUTTON_SLEEP="notify suspend_to_disk". In this case, the user is informed about the suspend by a pop-up window in X or a message on the console. Subsequently, the event EVENT_GLOBAL_SUSPEND2DISK is generated, resulting in the execution of the mentioned actions and a secure system suspend mode. The internal action notify can be customized using the variable NOTIFY_METHOD in /etc/sysconfig/powersave/common.

/etc/sysconfig/powersave/cpufreq

Contains variables for optimizing the dynamic CPU frequency settings and whether the user space or the kernel implementation should be used.

/etc/sysconfig/powersave/battery

Contains battery limits and other battery-specific settings.

/etc/sysconfig/powersave/thermal

Activates cooling and thermal control. Details about this subject are available in the file /usr/share/doc/packages/powersave/README.thermal.

/etc/sysconfig/powersave/scheme_*

These are the various schemes that adapt the power consumption to certain deployment scenarios. A number of schemes are preconfigured and can be used as they are. Custom schemes can be saved here.

32.4.2 Additional ACPI Features

If you use ACPI, you can control the response of your system to ACPI buttons (power, sleep, lid open, and lid closed). Configure execution of the actions in /etc/sysconfig/powersave/events. Refer to this configuration file for an explanation of the individual options.

HINT: Configuring ACPI Buttons

The settings in /etc/sysconfig/powersave/event are only taken into account if no power management applet is run on the user's desktop (i.e. KPowersave or GNOME Power Manager).

EVENT_BUTTON_POWER="wm_shutdown"

When the power button is pressed, the system responds by shutting down the respective window manager (KDE, GNOME, fvwm, etc.).

EVENT_BUTTON_SLEEP="suspend_to_disk"

When the sleep button is pressed, the system is set to the suspend-to-disk mode.

EVENT_BUTTON_LID_OPEN="ignore"

Nothing happens when the lid is opened.

EVENT_BUTTON_LID_CLOSED="screen_saver"

When the lid is closed, the screen saver is activated.

EVENT_OTHER="ignore"

This event happens if an unknown event is encountered by the daemon. Unknown events include ACPI hot keys on some machines.

Further throttling of the CPU performance is possible if the CPU load does not exceed a specified limit for a specified time. Specify the load limit in PROCESSOR_IDLE_LIMIT and the time-out in CPU_IDLE_TIMEOUT. If the CPU load stays below the limit longer than the time-out, the event configured in EVENT_PROCESSOR_IDLE is activated. If the CPU is busy again, EVENT_PROCESSOR_BUSY is executed.

32.4.3 Troubleshooting

All error messages and alerts are logged in the file /var/log/messages. If you cannot find the needed information, increase the verbosity of the messages of powersave using DEBUG in the file /etc/sysconfig/powersave/common. Increase the value of the variable to 7 or even 15 and restart the daemon. The more detailed error messages in /var/log/messages should help you to find the error. The following sections cover the most common problems with powersave and the different sleep modes.

ACPI Activated with Hardware Support but Functions Do Not Work

If you experience problems with ACPI, use the command dmesg|grep -i acpi to search the output of dmesg for ACPI-specific messages. A BIOS update may be required to resolve the problem. Go to the home page of your laptop manufacturer, look for an updated BIOS version, and install it. Ask the manufacturer to comply with the latest ACPI specification. If the errors persist after the BIOS update, proceed as follows to replace the faulty DSDT table in your BIOS with an updated DSDT:

  1. Download the DSDT for your system from http://acpi.sourceforge.net/dsdt/index.php. Check if the file is decompressed and compiled as shown by the file extension .aml (ACPI machine language). If this is the case, continue with step 3.

  2. If the file extension of the downloaded table is .asl (ACPI source language), compile it with iasl (package pmtools). Enter the command iasl -sa file.asl. The latest version of iasl (Intel ACPI compiler) is available at http://developer.intel.com/technology/iapc/acpi/downloads.htm.

  3. Copy the file DSDT.aml to any location (/etc/DSDT.aml is recommended). Edit /etc/sysconfig/kernel and adapt the path to the DSDT file accordingly. Start mkinitrd (package mkinitrd). Whenever you install the kernel and use mkinitrd to create an initrd, the modified DSDT is integrated and loaded when the system is booted.

CPU Frequency Does Not Work

Refer to the kernel sources (kernel-source) to see if your processor is supported. You may need a special kernel module or module option to activate CPU frequency control. This information is available in /usr/src/linux/Documentation/cpu-freq/*.

Suspend and Standby Do Not Work

ACPI systems may have problems with suspend and standby due to a faulty DSDT implementation (BIOS). If this is the case, update the BIOS.

When the system tries to unload faulty modules, the system is arrested or the suspend event is not triggered. The same can also happen if you do not unload modules or stop services that prevent a successful suspend. In both cases, try to identify the faulty module that prevented the sleep mode. The log file /var/log/pm-suspend.log contains detailed information about what is going on and where possible errors are. Modify the SUSPEND_MODULES variable in /usr/lib/pm-utils/defaults to unload problematic modules prior to a suspend or standby.

Refer to http://www.opensuse.org/Pm-utils and http://www.opensuse.org/S2ram to get more detailed information on how to modify the suspend and resume process.

32.4.4 For More Information