This package unifies the control of power managing facilities on your
PC. It supports hardware based on ACPI, APM, IDE-disks and CPU
frequency scaling techniques. For proper functionality you should have
arunning acpid daemon - since only one process can access
/proc/acpi/event and at least HAL and powersaved need ACPI
events, we use acpid as an "event distributor". To achieve this you
should configure acpid to not process any events, otherwise you will
get undefined results since powersaved also executes actions based on
ACPI events. Just removing everything in /etc/acpi/events and
putting an empty file named "default" in there should be enough for
that.
If your PC does not contain all of the described hardware above (APM and ACPI are mutal exclusive) you should still run this daemon to manage power saving related tasks. The overhead is small and you will be provided with a unique interface and configuration environment. And you can still use this tool if some hardware should change (e.g. booting ACPI instead of APM when kernel provides better ACPI support). The daemon will automatically detect your hardware and support available features.
The Powersave Daemon is some kind of policy decision maker for servers or just for systems where no nice graphical user interface like kpowersave or gnome-power-manager is available. It also sets the initial power management settings on booting, before another policy decision maker starts up.
Among others, the Powersave Daemon provides the following features:
Get the latest packages from https://sourceforge.net/projects/powersave
If you are a developer and want to have a look at the code or the internal design, you may look at the Doxygen documentation.
Be aware that this project is under developement. If you find outdated or incorrect documentation or any bug, please drop us a mail on powersave-devel@forge.novell.com (subscribe here: http://forge.novell.com/modules/xfmod/maillist/subscribe.php?group_id=1438&list=powersave-devel)
The powersave daemon defines three battery states. They will only be taken into account if no other application caring about power management (such as kpowersave or gnome-power-manager) is running.
The user can set the limits when a battery state changes via these variables:
BATTERY_WARNING=12
BATTERY_LOW=7
BATTERY_CRITICAL=2
/etc/powersave/battery file.
Where the remaining capacity should be highest for the warning and
lowest for the critical state.
You can specify an action what should happen when a battery state is
sub-ceded (see Events) in the /etc/powersave/events file.
In rare cases the machine might have a smart battery bus system. This is currently not supported by the Linux kernel. However, a workaround exists which includes to dissassemble and patch your DSDT (see DSDT). Rich Townsend has come up with a sourceforge project (see https://sourceforge.net/projects/sbs-linux/) that provides a patch for your DSDT. Be aware that on most distributions (SUSE Linux, Ubuntu, Mandrake, ...) you do not need to recompile your kernel (you can skip some steps described there), but you can simply add the DSDT to your initrd (see DSDT).
AFAIK a lot new ACER models do use the smart battery subsystems (Others might as well. If you have one you could mail me your machine model and I will setup a list if I have enough mail@renninger.de).
You find a report/manual how to get smart battery support and other ACPI problems solved for the:
The Powersave Daemon will only care about CPU frequency scaling if no other application caring about power management (such as kpowersave or gnome-power-manager) is running.
To check if CPU Frequency scaling is supported, start powersaved and have
a look at: /sys/devices/system/cpu*/cpufreq -> there must
exist files. If you don't find any, but you know your system should support
it, browse/post the mailing list: cpufreq@www.linux.org.uk.
All configuraton variables are described in detail in the
/etc/powersave/cpufreq configuration file.
You may want to override these (or other) variables in the scheme_* files. A scheme and its configuration is activated when switching between AC and battery power source or could be switched by using:
powersave -x (to display available schemes)
powersave -e scheme_name (to switch to a specfic scheme)
You may want to edit existing or create new schemes:
On SUSE systems this can be done by using the YAST power-management module
(recommended) or by modifying the config files (/etc/powersave/scheme_*)
To add an additional scheme by hand, just copy one scheme file and rename it
to scheme_"whatever" (in the same directory). Be sure that you modify the
SCHEME_NAME variable in the file or the powersave daemon will be confused.
Restart the powersaved or send a SIGHUP signal after you modified any config files.
For some specific machines, you need special hacks for loading the cpufreq modules. The ones we know of are listed here, with a description of the chipset, so you can try this out on similar machines. Note that you may need to reboot the machine (or at least unload all cpufreq modules including speedstep_lib and freq_table and after that restart powersaved) to get those working since powersaved does not unload the modules at stop and you need to reload the modules to make those settings effective). Also note that after changing modprobe.conf you need to run "depmod -a" first.
List of machines:
SHARP PC-AR10
=============
lspci excerpt:
0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
0000:00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
/proc/cpuinfo excerpt:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 647.300
cache size : 256 KB
CPUFREQD_MODULE="speedstep-smi"
CPUFREQD_MODULE_OPTS="smi_sig=1 smi_cmd=0x82 smi_port=0xb2"
COMPAQ ARMADA E500
==================
These are available in different flavours. I have seen one, (with a P III
Coppermine, 800MHz) where adding "options speedstep_lib relaxed_check=1"
to /etc/modprobe.conf.local and setting
CPUFREQD_MODULE="speedstep-smi" was enough to get it going, another
one (P III Coppermine, 700MHz) needs those and additional
CPUFREQD_MODULE_OPTS="smi_cmd=0x82 smi_port=0xb2".
This one has a (lspci):
0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
0000:00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
and (/proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 6
cpu MHz : 697.155
cache size : 256 KB
IBM Thinkpad T20 (model 2647-21G)
=================================
0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
0000:00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 1
cpu MHz : 647.401
cache size : 256 KB
P III Coppermine, 650MHz, just set CPUFREQD_MODULE="speedstep-smi".
These settings will only be taken into account if no other application caring about power management (such as kpowersave or gnome-power-manager) is running.
If you are working on an ACPI system you can customize the behaviour of your ACPI
buttons.
These are:
Search for the button event configuration variables in
/etc/powersave/events (also see Events).
You may also be able to catch other (multimedia) buttons that are ACPI driven. However, this mainly depends on your system. If your system provides ACPI driven buttons you can use one of the provided scripts or implement your own (see Scripts).
First: Thermal management is only available on ACPI systems.
Second: Thermal management is buggy on a lot of machines (mostly by BIOS, it's also possible that you hit a kernel bug, see Lists how to report a kernel bug to get it solved). It is also very buggy in powersaved, if something does not work, report it ;-)
Examine the directory(ies) in /proc/acpi/thermal_zone/*/
COOLING_MODE variable
satisfies your needs (set it to active or passive in your
scheme_* configuration files, see below - Configuration Variables).
/proc/acpi/thermal_zone/*/trip_points or use
powersave -T.
Your system should at least support a passive, even better one or more
active trip points (if not, nag your vendor to export temperature limits
by BIOS, it is really easy, but a lot of vendors do not care much about
the ACPI spec...)
If your system supports trip points you can override the temperature limits
for your needs (described below in Configuration Variables).
watch -n2 powersave -T
cat /dev/zero > /dev/null (high processor usage)
powersave -f
to speed and warm up your processor (powersave -A to switch back
to dynamic mode).
additionally you could close the slot to the fan (carefully...)
The thermal zone(s) which temperature(s) is rapidly increasing, is(are) the
interesting one.
Adjust the trip points of this thermal_zone (use number from powersave -T)
using the variables described in 2.6.
Relevant configuration variables are in
/etc/powersave/thermal and the scheme configuration files
You may want to create e.g. a scheme cool/hot and activate it when
you need a cool/fast system using the kpowersave front-end or the
-x -e parameters of the powersave binary.
ENABLE_THERMAL_MANAGEMENT="yes"
Relevant general configuration variables for each scheme: (/etc/powersave/scheme_*):
COOLING_POLICY="passive"
active - The hardware is preferably cooled by the fan
passive - The hardware is preferably cooled through
lowering the cpu frequency and throttling.
This is rarely supported by HW, See /proc/acpi/thermal_zone/*/cooling_mode
THERMAL_CRITICAL_0="95"THERMAL_HOT_0="90"THERMAL_PASSIVE_0="35"THERMAL_ACTIVE_0_0="40"THERMAL_ACTIVE_0_1="42"Use these variables to override the temperature trip point settings exported
by the BIOS (in degrees Celsius, see /proc/acpi/thermal_zone/*/trip_points)
The number at the end of each variable defines the thermal zone for which
the value should be active. Use the powersave -T command to find
supported thermal zones and their default trip point settings.
You might want to use the setDefaultTrippoints.sh script to fill your scheme_* conf files with your BIOS settings to easily override them.
The machine is switching on fans when active trip point temperature limits are reached.
When reaching the passive trip point, the kernel will lower the CPU's frequency (if CPU frequency switching is supported by your CPU) and throttle the CPU down when the passive trip point is exceeded.
By default the passive trip point (tp) is far above the active tps. For a cool and quiet system you may want to change this similar to above example settings. However these values are very HW dependant and you therefore have to fiddle around a bit to find out the best settings for your machine.
Try to find out which thermal zone directly refers to the processor as described above. A low value for passive should avoid fan activity but may slow down your machine if it exceeds the trip point's limit. The throttling is done by the kernel itself, the maximum throttling variable is not used in case of the passive limit is reached. Increase the active trip points values (if supported) to additionally avoid fan activity.
If a trip point is not supported by your BIOS (e.g. hot) you cannot use it -> write an email to your vendor he should support all of them, even you have a workstation.
The Powersave Daemon doesn't do suspend to disk/ram itself anymore. This functionality moved to the PM-Utils project. See http://en.opensuse.org/Pm-utils for more information. This documentation can just be seen as additional information source for suspend on linux.
Please read this notes before trying to use the suspend feature.
First, some definitions so there's no confusion about the used terms:
With ACPI it is pretty straightforward: the operating system has to prepare itself for the upcoming sleep state and then enter it with (little) help of BIOS routines. This is still work in progress and not finished.
Unfortunately, things get a bit more complicated when using APM. With APM, there are only two states: standby and suspend. So with APM you get the following possible states:
powersave -U, kpowersave: Suspend to Disk).
Please note that suspend with ACPI is still experimental and may not
work on all hardware. Especially suspend to RAM (ACPI S3) is very
problematic on many machines.
To avoid trouble for unwary users, we have disabled suspend and
standby for normal users in the default configuration on non-notebook
machines.
If you'd like to try out suspend, you have to change the values of
DISABLE_USER_SUSPEND2DISK, DISABLE_USER_SUSPEND2RAM or
DISABLE_USER_STANDBY in /etc/powersave/sleep to "no" or
run the powersave command as superuser root.
|
Warning: failing suspend/standby-cycles can lead to filesystem corruption and loss of data, so try this only if you know what you are doing. For the first tries it is advisable to close all open files and have only a small number of programs and services active on the machine. |
The powersave package provides a uniform interface to both APM and
ACPI but there are still some differences, which have to be adressed
by the configuration settings.
You can determine the powermanagement system used by your machine with
the command "powersave -S".
Using ACPI, suspend to disk is known to work better than standby /
suspend to RAM, so try this first.
For first tests it is advisable to set DEBUG to 7 or 15 to
increase the verbosity of the powersaved and of the proxy scripts. You
will find a lot of diagnostics output in /var/log/messages after
restarting powersaved.
Also, there are some modules/services which are known to cause problems
with suspend, so be sure you installed the newest update kernel.
3D acceleration for graphic cards is known not to work with suspend
sometimes (the binary only drivers from NVidia and ATI are a prominent
example).
However, this issue is being worked on and you already may be able to
suspend with acceleration enabled. If you experience any hardware problems
on suspend, we would appreciate to be informed about the hardware type
that fails (for contact have a look at the end of this file).
So now you are ready to go? Fingers crossed?
Well, let's try. Open a terminal and issue "powersave -U". If
everything goes well, the machine should switch to a text console after
a few seconds, showing you some progress marks and finally power off.
Power it back on and it should begin a normal boot but then recognize
the saved image and resume. If everything goes well, the machine should
be at the same state it was when the suspend started.
What can go wrong?
ps auxfww".
/etc/powersave/sleep
to UNLOAD_MODULES_BEFORE_SUSPEND.
UNLOAD_MODULES_BEFORE_SUSPEND.
/var/log/suspend*.log. A state file that
records which services were stopped and which modules unloaded is in
/var/lib/suspend*-state.
Since suspend is in constant development and we don't have the possibility to test on every available hardware, we appreciate any feedback either via http://www.suse.com/feedback or on the suse-laptop mailinglist to which you may subscribe via http://www.suse.com (and even if you are trying suspend on a desktop machine, you are welcome on the suse-laptop mailinglist). Note, that this list is mostly german speaking, but you are generally welcome in english, too.
###############################################
### BIG FAT WARNING BIG FAT WARNING BIG FAT ###
###############################################
|
severe file system corruption may occur which means: DANGER, DATA LOSS AHEAD. Please back up important data before trying suspend to RAM. In my experience, once you have found a setting that works, it is not dangerous at all, but you should keep an eye open. Use at your own risk. |
suspend to RAM with ACPI (S3) is still very experimental, but there are several machines that are known to work. There are several "hacks" that can be tried to actually get the machine to resume (suspend is usually not the problem, just the resume ;-)
Efforts to change this are going on, work is being done to implement a
"whitelist" of machines that are known to support suspend to RAM and the
needed workarounds (if any). This work is done in the "suspend" package
http://sourceforge.net/projects/suspend and there in the "s2ram" binary.
Support for s2ram is integrated into powersaved, it can be configured via
configuration variables in /etc/powersave/sleep.
On machines that are known to s2ram, no configuration should be necessary.
On machines that are unknown to s2ram (check with sram -n as root), you
need to set SUSPEND2RAM_FORCE=yes to override the detection, then configure
the workarounds (if needed) with the variables described below:
First, there are several kernel parameters, that can be tried out. Just
add them to your "kernel"-line in /boot/grub/menu.lst. More information
about those can be found in /usr/src/linux/Documentation/power/video.txt.
You can try the following:
acpi_sleep=s3_biosacpi_sleep=s3_modeacpi_sleep=s3_bios,s3_modevga=normal", which will give you a simple text console
during boot (sorry, no fancy graphics for this one). You need to remove
the existing "vga=0x317" or similar from the kernel command line and add
"vga=normal" instead. Only one "vga=..." should be present.vga=normal can
(and probably has to) be combined with the acpi_sleep=... parameters from
above.
The acpi_sleep parameter can also be set at runtime in /proc/sys/kernel/acpi_video_flags,
or with the s2ram tool. In powersaved, the SUSPEND2RAM_ACPI_SLEEP
variable sets this, see the comment in the configuration file for details.
Another possibility is to save and restore the VBE settings of the graphics
card with the tool "vbetool". This is experimental and you should only
use this if you know what you are doing. Example scripts for vbetool usage
can be found in the contrib directory.
Using s2ram, VBE saving/restoring can be achieved with the SUSPEND2RAM_VBE_SAVE
variable. VBE POST can be done with SUSPEND2RAM_VBE_POST. Again, see the
comments in the config file for details.
In the (not too distant) past, often the advice was given to suspend from a runlevel without X, but due to recent improvements with various X server modules, this may not be the best advice anymore since in fact on some machines only the X server is capable of bringing the graphics card back correctly from suspend to RAM. On the Dell D600 for example, the display backlight stays off until the X server reinitializes the card.
There is a list of working machines and tricks how to get them work in the
linux kernel Documentation. If the linux kernel sources are installed, the
list can be found at
/usr/src/linux/Documentation/power/video.txt.
If you find other machines that work with one of these (or if you cannot get machines mentioned here to work at all) feel free to contact us via the powersave-users mailinglist.
Warning: if you are using crypto-filesystems, a suspend to disk will dump your passphrase for these to the swap partition IN CLEAR TEXT. Either unmount these partitions before suspend or do not use suspend to disk at all. Sorry about that.
These settings will only be taken into account if no other application caring about power management (such as kpowersave or gnome-power-manager) is running.
You can define different schemes that should take place if you plug/unplug the AC adapter. You propably want to ajust your system to drain less power when you work on battery, and to increase performance if you work on AC power.
In /etc/powersave/common set the scheme that should be used:
AC_SCHEME="performance"
BATTERY_SCHEME="powersave"
The schemes are config files in /etc/powersave. Their names
must be in the format scheme_SCHEMENAME.
In the above case there are at least two scheme config files:
scheme_performance and scheme_powersave (provided). You can set up your
own scheme configurations, modifiy existing (not recommended, at least
backup them). SUSE also provides a configuration module with the
YaST2 power-management module.
Currently you can influence the CPU frequency policy, IDE-disk power
save features, temperature settings and some more.
Have a look into the provided scheme files
(e.g. /etc/powersave/scheme_powersave) for available
variables and syntax.
You can also override all general settings from any powewersave
configuration file (/etc/powersave/*), even reconfigure
events (see Events). For example you could reset the battery level limits
with a "on_work" scheme. You also can e.g. shutdown the machine with the one scheme
and suspend the machine with another scheme when reaching a specific
battery limit.
You could also define your own scripts to be processed for specific events (see Scripts).
Events are triggered from the daemon when Hardware changes are recognised or user requests have been made.
Have a look into /etc/powersave/events where you may want to
change the default behaviour how events get processed.
The syntax is:
EVENT="action1 action2 action3 ..."
Events are triggered e.g. when:
If an event happens, the configured actions for this event are processed from left to right.
There are internal (processed from the daemon internally) and external
actions (executed scripts located in /usr/lib/powersave/scripts)
that can be assigned to each event.
Internal actions (name is reserved, scripts must not be named like that) currently are:
/usr/lib/powersave/scripts, the name of the executable is the event
name.
Example: put EVENT_OTHER="debug_events" into
/etc/powersave/events to debug the hotkey events on some
ASUS notebooks (the asus_acpi module has to be loaded) and watch
/var/log/messages for the output of the debug_events script..
See the next chapter (Scripts) how to write your own scripts for events.
All scripts must use powersaved_script_return to tell powersaved when the event is finished. Otherwise no other event will be started until the previous event times out (after 120 seconds).
The syntax is:
powersaved_script_return $EVENT_ID $RET "$MESSAGE"
$EVENT_ID is the number given to the script as positional parameter $4.
$MESSAGE is just informal, except for return codes 2 and 4.
Possible return codes $RET are:
0 - execution of the event finished successfully
1 - execution of the event finished, but failed
2 - request a popup by the client, event not finished
3 - request a screenlock by the client, event not finished
4 - request a progress bar popup by the client, event not finished
There may be additional codes added in the future.
This is example code to use in your own scripts:
#!/bin/bash
# example script for events in powersaved
# parameters:
# - $1 event type
# - $2 current scheme
# - $3 ACPI event line
# - $4 Event-ID. Needed for $SCRIPT_RETURN
#
# source helper_functions to get $PATH, $SCRIPT_RETURN, EV_ID (among others)
. /usr/lib/powersave/scripts/helper_functions
# Note: this sets a trap on "EXIT", so you must exit the script via the
# (also provided) EXIT function after calling $SCRIPT_RETURN
# If you don't call EXIT, the trap will call $SCRIPT_RETURN with return code 1
#
# this is stupid, you'd like to do something useful here :-)
case $3 in
button*)
logger "button-event"
;;
*) logger "non-button-event"
$SCRIPT_RETURN $EV_ID 1 example script failed"
EXIT 1
;;
esac
# always call $SCRIPT_RETURN before exiting:
$SCRIPT_RETURN $EV_ID 0 "example script succeeded"
EXIT 0
There are various scripts in the contrib directory (the "example_event_script" has comments on what is provided by helper_functions) or have a look at the simple "debug_events" script in the scripts directory for other examples.
Namespace: com.novell.powersave
Acpi events from /proc/acpi/events
Powersave events
Possible events:
Daemon or script progress (e.g. 'unloading modules 40%)
Return types:
Simple messages, error messages or notifications
D-BUS Example:
signal sender=:1.5 -> dest=(null destination) interface=com.novell.powersave; member=acpi_event 0 string "button.power"
When an event occurs the clients may want to use the Request interface to reread specific values (e.g. request "rem_charg_time_battery" after a event "battery.info", or request "schemes" after a event "daemon.scheme.changed"
-> All requests do not have any parameters.
Get all Powersave schemes
Return types:
Get a specific scheme description
Param:
Return types:
Check whether daemon is up and replies
Set machine into suspend to disk mode
Set machine into suspend to ram mode
Set machine into standby mode
Enabled a single CPU
Param:
Disable a single CPU
Param:
Set a powersave scheme
Param:
Notify connected clients of any progress going on
All calls to the bus get a return/error message replied.
Return messages include following types:
The error ids can be found in powerlib.h as defines.
If an error happens the message will be an error reply (as specified by dbus). Following errors can be checked for all method calls/signals:
General Error
No connection Error (The daemon is probably not running)
No rights Error (The client is not allowed to speak with the daemon)
Invalid Paramet (The client sent bullshit)
Following request/actions may return specialised errors:
Following errors may occur on some actions/requests and must be checked by the client if such a action/request is made:
Interface: com.novell.powersave
Interface: com.novell.powersave
User management in current versions is done by DBus.
A configuration file (powersave.conf) is placed in the DBus configuration directory (current default: /etc/dbus-1/system.d). There you can configure who is allowed to connect to the DBus interface and request system information or e.g. trigger a suspend, or whatever.
The heart of the package is the daemon
(/usr/sbin/powersaved). It listens for hardware changes
and checks e.g. the CPU load to adjust the CPU frequency
dynamically.
There are a fixed amount of events that the daemon my throw. The events could be triggerd by the underlying hardware/kernel and the daemon just forwards them (e.g. ACPI events) or the daemon can generate his own events when it recognises hardware changes (e.g. low/high CPU usage, changed battery levels, ...). See Events for an complete overview of all events and Scripts how you can use them in your own scripts and programs.
This binary (/usr/bin/powersave) provides general information about
your system (APM/ACPI, battery, throttling, CPU frequency, ...).
For some functionalities you may need a running daemon. The binary then connects to the daemon through a socket and sends its requests (e.g. suspend, standby, change CPU freq policy, ...).
The modifications could only be temporarily. They could e.g. be overridden by the policy of the daemon. E.g. if you plug/unplug AC adapter and another power scheme (see Schemes) is activated which then adjusts your power policy as you specified them for this scheme.
The binary should mainly give you some information of your hardware. Please have a look at the manpage for details.
If you intend to write your own power manageing program you can make use of the provided libraries. All libraries are build statically and shared by the build system.
The libpowersave.a/libpowersave.so library directly accesses kernel functions (through /proc, /sys or ioctl) and could be very useful to gain hardware information (Have a look into powerlib.h for provided functions).
The library is currently converted to make use of HAL functions to gain hardware information. You may want to have a look at the code and also directly make use of HAL to gain that information. However, HAL lacks in some functionalities, therefore there are still functions that access /proc and /sys files directly.
Only exists in old versions, deprecated, don't use.
Use the DBus interfaces instead.
Only exists in old versions, deprecated, don't use.
Use the DBus interfaces instead.
This library should make it a bit easier to connect to the powersave daemon over the DBus system bus.
However, you should make use of the DBus bindings directly if possible. They are offered in different languages (perl, QT, glib, phython, ...).
See DBus what information you can query from the powersave daemon and what actions(e.g. suspend, cpufreq policy, ...) you can trigger.
The DSDT is one of several tables that is exported by the ACPI BIOS parts of your system from ROM to RAM. The BIOS tells the Operating System where to find these tables and loads/uses them.
The DSDT table actually is code that can be executed by the Operating System and the BIOS to communicate with each other.
This code (the DSDT) is byte-code (similar to compiled Java code) that is interpreted by the kernel. It can easily be extracted, disassembled, modified (errors corrected, debug info attached, ...) and compiled to byte-code again. You can attach the modified DSDT to your initrd/initramfs (the modular part of the kernel that is loaded very early at boot time). After the BIOS exported the ACPI tables to RAM and tells the kernel where to find them, the kernel can replace e.g. the DSDT with your modfied/corrected one. Having said this, two points should be very important for you:
For some distributions you need a kernel patch to be able to do that. (not needed for most distributions like current versions of SUSE Linux, Ubuntu, Mandrake and others) You find the patch here: http://gaugusch.at/kernel.shtml
You can disassemble the byte-code of your DSDT. You then have a C-like bunch of functions that were exported by your BIOS. You can modify and add debug statements to it, recompile it and let the kernel override the one exported by BIOS with your modified/fixed one. The pmtools package has to be installed for this. You do this by:
Find a DSDT for your laptop under: http://acpi.sourceforge.net/dsdt/tables/
In the SUSE Linux distribution for example you can override your DSDT by:
You can download SVN trunk tarballs via the webSVN frontend:
http://forge.novell.com/modules/xfmod/svn/svnbrowse.php?repname=powersave
svn checkout svn+ssh://anonymous@forgesvn1.novell.com/svn/powersave/trunk
When prompted for the password, enter "anonymous". You currently have to enter this twice, once for ssh and once for subversion.
The module you wish to check out must be specified as modulename
(either 'powersave', 'kpowersave' or 'wmpowersave').
When prompted for the password, simply enter "anonymous".
We'll try to let trunk stay in good shape all the time but well, you never know. Tell us if you find bugs or have problems compiling.
In the powersave directory do:
autoreconf -fi
./configure --prefix=/usr./configure --help gives further instructions (recommended))
This list is probably not complete, but gives an overview:
We tested (or got reports for) the powersave package sources on following distributions:
| SUSE | Mandrake | Debian | Red Hat | Gentoo | ALT-Linux
| |
| Compiled | x | x | x | not tested | x | x
|
| Installed/Works | x | x | x | not tested | x | x
|
| Package exists | x | N.A. | N.A. | N.A. | N.A. | x
|
We really like to see packages for more distributions. It cost me too much time to only install the above mentioned distributions to test-compile and install the sources.
If you think you have knowledge enough on the distribution you are working on, you are welcome to submit some build scripts. We will integrate them into the SVN / tarballs and will try to build packages for new versions regularly.
Distribution specific patches will gladly be committed (as long as they don't break anything). Please contact me if you have any questions (mail@renninger.de)
Currently I know of four clients that make use of or are based on the powersave daemon functionalities:
The WMpowersave client is currently maintained by Holger Macht, (holger@homac.de).
/etc/powersave/ graphically.
Only on SUSE right now.
WMpowersave and gkrellm-powersave are hosted on the powersave project pages at http://sourceforge.net/projects/powersave and http://forge.novell.com/modules/xfmod/project/?powersave
Version 0.9
1) Configuration
dropped variables for schemes in /etc/sysconfig/powersave/schemes_*:
POWERSAVE_DISABLE_DISPLAY_SETTINGS=
POWERSAVE_DISABLE_SCREEN_SAVER=
POWERSAVE_DISABLE_DPMS=
POWERSAVE_DPMS_STANDBY=
POWERSAVE_DPMS_SUSPEND=
POWERSAVE_DPMS_OFF=
These settings are no longer handled by the helper scripts but by the
graphical clients like kpowersave (which can do this more easily).
2) events / scripts in /usr/lib/powersave/scripts
It was already possible in version 0.8 to put executables into
/usr/lib/powersave/scripts and use the names of these executables as event
names.
In version 0.8, only the exit status of the script was used to determine
success or failure. In version 0.9, you must now use
/usr/lib/powersave/scripts/powersaved_script_return to tell powersaved if
the event was executed successfully or not. Read more in README.events
3) Clients
Clients can now register with powersaved and get notified for specific
events, so polling is no longer needed. Take a look at the "testclient"
source code for further information.
Clients can also be notified by e.g. proxy scripts to popup a messagebox,
a progress bar or to lock the screen.
#########################################################################
Version 0.8
1) Configuration
configuration merged into one directory.
powersave.conf (etc/) and common (/etc/sysconfig/powersave)
have been merged into the files common, events, cpufreq, thermal,
sleep and battery.
Following config Variables have are new or have changed:
New general variables:
/etc/sysconfig/powersave/cpufreq:
POWERSAVED_CPU_HYSTERESIS=
POWERSAVED_CONSIDER_NICE=
POWERSAVED_JUMP_CPU_FREQ_MAX_LIMIT=
/etc/sysconfig/powersave/events:
POWERSAVE_EVENT_DAEMON_SCHEME_CHANGE=
POWERSAVE_EVENT_TEMPERATURE_CRITICAL=
POWERSAVE_EVENT_TEMPERATURE_HOT=
POWERSAVE_EVENT_TEMPERATURE_PASSIVE=
POWERSAVE_EVENT_TEMPERATURE_ACTIVE=
POWERSAVE_EVENT_TEMPERATURE_OK=
/etc/sysconfig/powersave/thermal:
POWERSAVE_ENABLE_THERMAL_MANAGEMENT=
new variables for schemes in /etc/sysconfig/powersave/schemes_*:
POWERSAVE_DISABLE_DISPLAY_SETTINGS=
POWERSAVE_DISABLE_SCREEN_SAVER=
POWERSAVE_DISABLE_DPMS=
POWERSAVE_DPMS_STANDBY=
POWERSAVE_DPMS_SUSPEND=
POWERSAVE_DPMS_OFF=
Because of confusing naming of sleep states those have been renamed:
there was:
suspend (ACPI S4, APM suspend)
standby (ACPI S3, APM standby)
now there is:
suspend to disk (ACPI S4, APM suspend)
suspend to ram (ACPI S3, APM suspend)
standby (ACPI S1, APM standby)
Therefore following variables changed in
/etc/sysconfig/powersave/events and
/etc/sysconfig/powersave/sleep:
POWERSAVE_EVENT_GLOBAL_SUSPEND2DISK=
POWERSAVE_EVENT_GLOBAL_SUSPEND2RAM=
POWERSAVE_EVENT_GLOBAL_RESUME_SUSPEND2DISK=
POWERSAVE_EVENT_GLOBAL_RESUME_SUSPEND2RAM=
POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND2DISK=
POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND2RAM=
POWERSAVE_SUSPEND2DISK_RESTART_SERVICES=
POWERSAVE_SUSPEND2RAM_RESTART_SERVICES=
POWERSAVED_DISABLE_USER_SUSPEND2DISK=
POWERSAVED_DISABLE_USER_SUSPEND2RAM=
POWERSAVE_SUSPEND2DISK_DELAY=
POWERSAVE_SUSPEND2RAM_DELAY=
POWERSAVE_STANDBY_DELAY=
2) Thermal Management
Thermal management is supported from now on.
see README.thermal.
3) Switch Schemes Manually
Schemes can now switched by hand using the powersave -x (overview of
all schemes) and the powersave -e scheme_to_set (switch scheme)
parameters.
4) Socket Interface
Other progs can now query the daemon for:
AC state
Suspend_to_disk enabled by admin
Suspend_to_ram enabled by admin
Standby enabled by admin
Current cpufreq policy (powersave, dynamic, performance)
Battery state (no_bat, normal, warning, low, critical)
Battery charging state (unknown, charge/discharge, charge, discharge)
Remaining percent battery capacity
by one socket connect using the send_Action_get_States() and evaluate
the return value using evaluate_States(int64_t states, int data_to_evaluate)
(in libpower/powersave_daemonlib.c)
Other progs can also switch query for a list of existing schemes using
send_Action_get_all_Schemes(SchemeList* s) and switch schemes
using the send_Action_ActivateScheme(const char *schemeName).
5) Screen Saver / DPMS
Screensaver (at least KDE) can be enabled/disabled and DPMS values can
be modified depending on the current schemes.
This allows to configure a presentation scheme (no DPMS/Screensaver)
and a more effective powersave/battery scheme (more extreme DPMS values)
Use the following variables in the scheme configuration files:
POWERSAVE_DISABLE_SCREEN_SAVER
POWERSAVE_DISABLE_DPMS
POWERSAVE_DPMS_STANDBY
POWERSAVE_DPMS_SUSPEND
POWERSAVE_DPMS_OFF
Version < 0.7
Nothing known at the moment, see FAQ.
Nothing known at the moment.
Have a look in /var/log/messages. All errors and warnings are
logged there by default. You may additionally want to set up
verbosity: set DEBUG variable to 7 or even to 15 in
/etc/powersave/common and restart the powersave
service/daemon to isolate the error. Messages are again logged
to /var/log/messages.
If you experience ACPI related problems (normally logged in dmesg, or missing directories in /proc/acpi) (try: dmesg |grep -i acpi and watch out for errors).
Please visit the homepage of your laptop vendor and update your BIOS. Nag your vendor to stick to the newest ACPI specifications in their BIOS!
If they still occur you could try to find out why by debugging ACPI parts of your system (see ACPI_Debugging and to override your DSDT (see: DSDT).
See in the kernel source if your processor is supported:
/usr/src/linux/Documentation/cpu-freq/*
(You need to install the kernel-source package)
and if you need a special module or module option (see Cpufreq). If you need
a special module/option use following variables:
CPUFREQD_MODULE=""
CPUFREQD_MODULE_OPTS=""
/etc/powersave/cpufreq config file to set
them.
As older a battery as worse its capacity. But it may still work suitable, only the values delivered to the OS may be wrong.
Try:
See section above.
This is a feature, not a bug.
The processor's frequency is lowered if supported and
the processor is idle.
Try:
cat /dev/zero > /dev/null &
or
glxgears
The system's load should then be on 100% and the
processor should run at highest speed (see cat /proc/cpuinfo)
If you encounter following error using the powersave binary: Could not connect to daemon. Is the daemon running? Are you privileged to connect to the powersave daemon?
You probably have a DBus connection problem.
Check the security config file for the powersave daemon in
the DBus configuration (default: /etc/dbus-1/system.d/powersave.conf).
Try to restart the DBus daemon.
Do powersave -c. If POWERSAVE is returned your CPU always runs
on lowest frequency.
A slow system could of course have totally other reasons. Check your system (top, ps, ...).
Have a look in /proc/acpi/processor/*/throttling. If the state
is not T0 even your CPU load is high disable
throttling in your scheme configuration files (see Schemes).
Another reason could be that you use the p4-clockmod module
(verify by: lsmod |grep p4).
You should not do that. Throttling is done through another
interface. Using both slows down the CPU unpredictable.
Be sure this module is not used in /etc/powersave/cpufreq
or loaded in any other way.
If you have ACPI problems on your machine, you should first have a look at DSDT. Try to disassemble your DSDT and recompile it. If you have sever compiler errors, first try to fix them, override your system's DSDT with your modified one and possibly your problems are gone. If this does not help go on reading this section.
This section describes how you enable ACPI debug in SUSE kernels which was disabled due to performance problems. Other distributions may already have ACPI debug set or you need to do things slightly different.
ACPI debug is not set anymore in SUSE kernels since version 9.3. Therefore you need to compile your own kernel with slightly other configs set:
cd /usr/src/linux
cp arch/i386/defconfig.default .config
(Replace i386 with your architecture e.g. x86_64 on 64 bits systems.
Replace default (after defconfig.) with smp if you have a multi processor
system or a dual core or hyperthreaded CPU).
"CONFIG_ACPI_DEBUG_LITE=y" with "# CONFIG_ACPI_DEBUG_LITE is not set"
and
"# CONFIG_ACPI_DEBUG is not set" with "CONFIG_ACPI_DEBUG=y"
Be careful, that the strings are identical to the ones above as
the .config file is parsed by scripts. You could use make menuconfig
and disable ACPI_DEBUG_LITE and enable ACPI_DEBUG with a little
config front-end if you are unsure.
make
make install
/boot/grub/menu.lst file. Simply copy the first boot entry lines
and make sure to replace the /boot/vmlinuz and /boot/initrd entries to
point to the right files (/boot/vmlinuz-2.6.Kernel_Version, ls /boot
and doing a copy paste helps).
echo XXX >/proc/acpi/debug_level
cat /proc/acpi/debug_level
echo 0x1F >/proc/acpi/debug_level
/var/log/messages whether you find useful information.
If you have some nice tricks e.g. how to get suspend to RAM working on your machine. Or maybe other special tricks for special machine types, please write to powersave-devel@forge.novell.com or if you are too lazy to subscribe directly write me mail@renninger.de.
This document is generated with the makeinfo tex parser. However, you don't need to speak tex to add or modify the sources.
It's really easy to add some text.
The document is part of the powersave daemon documentation. The subversion repository can be found at http://forge.novell.com/modules/xfmod/svn/svnpage.php/powersave/. See the section Get the SVN Sources at Compiling. Modify/Add files in the docs directory. Do a "makeinfo –html powersave.tex" in the docs directory and see whether you have some errors (you need to escape e.g. @ with @@). Send us the "diff -urN" of your modifications in the docs dir and we will include it.
If you like to help, you are welcome to join the powersave devel mailinglist.
If you have any trouble ask on one of the lists (email at where_to_subscribe):
The Powersave Developer List:
powersave-devel@forge.novell.com at http://forge.novell.com/mailman/listinfo/powersave-devel
The Powersave Users List:
powersave-users@forge.novell.com at http://forge.novell.com/mailman/listinfo/powersave-users
The acpi-devel List:
linux-acpi@vger.kernel.org at http://vger.kernel.org/vger-lists.html#linux-acpi
The cpufreq List:
cpufreq@lists.linux.org.uk at http://lists.linux.org.uk/mailman/listinfo/cpufreq
The SUSE Laptop List (German mainly):
suse-laptop@suse.de at http://www.suse.de/de/business/mailinglists.html
The powersave project is hosted on:
http://forge.novell.com/modules/xfmod/project/?powersave (including SVN)
and http://sourceforge.net/projects/powersave (new packages, discussions)
If you think you discovered an ACPI/cpufreq/or whatever related kernel bug,
please assign to the kernel bugzilla at:
http://bugzilla.kernel.org
and report your bug against the ACPI subsystem (you will get help for sure).
If you think you have a broken DSDT search:
http://acpi.sourceforge.net/dsdt
whether you find a fix. You can also submit a fixed DSDT there if you found
a bug in yours.
You can find the newest ACPI specification here:
http://www.acpi.info/
The kernel patches (already included in most distributions - see DSDT) to
override your DSDT at runtime is located at:
http://gaugusch.at/kernel.shtml
If your distribution does not already provide packages/tools to extract,
compile and dissassemble the DSDT you find the current iasl
(Intel ACPI Source Language) compiler here:
http://developer.intel.com/technology/iapc/acpi/downloads.htm
and userspace tools to reach the DSDT you find here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils