This packages was mainly intended for laptops. However more and more features (proper suspend/standby, configure ACPI Buttons, processor frequency scaling (also supported on multi processor machines), spinning down the hard disk, thermal management, ...) became available for workstations and even on servers.
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. It takes over functionalities of the APMD, ACPID, OSPMD and CPUFREQD (now called CPUSPEED) packages. Therefore you should not install at least you must not run daemons from these packages when you run the powersave daemon!
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 defines three battery states:
The user can set the limits when a battery state changes in the variables (default values): BATTERY_WARNING=12 BATTERY_LOW=7 BATTERY_CRITICAL=2 in the /etc/sysconfig/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/sysconfig/powersave/events file.
Asynchronous notification (/proc/acpi/battery/*/alarm) through ACPI battery alarm interface prevents daemon of polling battery. On many systems it resolves in a high CPU load because of bad hardware solutions if battery information is read out. If this interface is supported you get the lowest necessary battery read out. If FORCE_BATTERY_POLLING="yes" (default) is set to "no", the powersave daemon does not poll the battery anymore, but waits for hardware interrupts and ACPI events respectively.
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 modell 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:
ACER 1680 and 1980 (1681 WLCi) http://www.whoopy.it/linux
If CPU Frequency scaling is supported you can check after the starting the powersaved and having a look in: /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/sysconfig/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) and powersave -e scheme_name (to switch to a specfic scheme)
You can also use other front-ends like kpowersave or wm_powersave clients to switch schemes.
You may want to edit existing or create new schemes: This can be done by using the YAST power-management module (recommended) or (not all variables are editable through YAST) modify the config files themeselves (/etc/sysconfig/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".
If you are working on an ACPI system you can customize the behaviour of your ACPI buttons. These are: The Power and Sleep buttons and the Lid open/close "buttons".
Search for the button event configuration variables in /etc/sysconfig/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 ones (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)
Examine the directory(ies) in /proc/acpi/thermal_zone/*/
Relevant configuration variables are in /etc/sysconfig/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. (Only cooling mode is configurable through YAST (power-management module) for overridding your thermal trip points.)
_Relevant general configuration variables for each scheme: (/etc/sysconfig/powersave/scheme_*):
Activ - The hardware is preferably cooled by the fan. Passiv - The hardware is preferably cooled through This is rarely supported by HW. See /proc/acpi/thermal_zone/*/cooling_mode The cooling management is controlled by the kernel the powersaved has not much influence on this.
Use the variables to override the temperature trip point settings exported by BIOS (in degree Celcius). (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 out 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.
Please read this notes before trying to use the suspend feature.
Also, please take a look at the other README.* files in this documentation directory since they may cover other aspects related to suspend.
First, some definitions so there's no confusion about the used terms: * suspend-to-disk: saves the actual state of the machine to disk and powers it down. After this, external power and the batteries may be disconnected whithout losing data. At the next bootup, the previous state is resto- red and the computer resumes where the suspend was triggered. This is also called "suspend to disk" (STD), the ACPI term for this is ACPI S4. There are two ways for doing this: one is calling the BIOS and letting it save the state of the machine, this works mostly with APM BIOSes (see notes below), the other way is doing it ourselves in the kernel. The kernel implementation is called "swsusp" (for swap or software suspend) and is used with ACPI but can also be used for APM (see notes below). * suspend-to-RAM: most of the devices in the computer are deactivated (disk drives, graphics chips, even the CPU) and only the RAM is powered to keep its contents. At resume, only the individual devices need to be reinitialized and work continues relatively fast. This is also called "suspend to RAM" (STR). It depends on the particular hardware, how long a notebook can be kept in standby without need of an external power supply. Better machines will last several days while others run flat after only a few hours. The ACPI term for STR is ACPI S3. * standby: processes are stopped, some hardware is deactivated. The ACPI term for standby is ACPI S1. Not many machines support this state and the power savings are rather low.
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: - standby - APM standby state - suspend to RAM - APM suspend state. If the machine actually enters suspend to disk or suspend to RAM depends on the BIOS settings. - suspend to disk - machine suspends to disk using linux kernel swsusp method When the "suspend to RAM" routine is called, the BIOS actually decides if it does a STD or a STR. This can often be selected in the BIOS setup. Also, STD on APM machines almost always needs a special hibernation partition or a special file in a DOS partition which needs to be created with a vendor specific DOS or Windows program. On some machines with a Phoenix(R) BIOS you can create the special partition with the linux program "lphdisk". To confuse us even more, some machines (e.g. IBM Thinkpads) do STR or STD depending on which "suspend button" you have pressed (Fn-F4 is STR, Fn-F12 is STD) but there is no way for the powersave daemon to select if it wants to do STR or STD via standard APM BIOS calls. We have therefore decided to implement swsusp also for APM machines that is triggered on the STD powersave methods (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 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/sysconfig/powersave/sleep to "no".
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".
With APM, you rarely need to stop services and unload modules before suspending to ram or disk, so there should be no need for further configuration, you can probably just empty the corresponding variables in /etc/sysconfig/powersave/sleep. Note that many drivers have changed in kernel 2.6 with regard to power management and may behave differently now compared to kernel 2.4 (This only applies for the APM sleep methods standby and suspend to disk).
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 NVidia drivers 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).
To use swsusp with ACPI or APM there must exactly one swap partition be configured. This partition must be passed to the kernel via the "resume="-paramerter, usually in /boot/grub/menu.lst or /etc/lilo.conf (this is done automatically by YaST during the installation).
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? - The machine does not switch to the text console and shutdown, it seems just "nothing is happening". Before the actual suspend process starts, some drivers are unloaded and some services are stopped. If unloading of a module is not possible, a message box will pop up and a message is written to the log. Look into /var/log/messages for failures to unload modules or stop services. The messages of the powersave daemon start with "powersaved" or "powersave". If you see nothing in the log, look for hanging processes trying to remove modules and stop services with "ps auxfww". - The machine reboots hard during resume. This is usually caused by incompatible device drivers. If it will retry the resume on the next boot, you have to pass the "noresume" option at the boot prompt or boot the "failsafe" menu entry once. Add suspicious modules in /etc/sysconfig/powersave/sleep to UNLOAD_MODULES_BEFORE_SUSPEND. - The resume seems to work fine, but some components do no longer work (e.g. USB Mouse or the network card). This is usually caused by drivers not fully implementing powermanagement support and can often be worked around by unloading the driver module before suspend and reloading it after resume. Add the module to UNLOAD_MODULES_BEFORE_SUSPEND.
To help debugging and finding the "bad" modules, you'll find a list of modules which were loaded and information about memory usage before your last suspend event in /var/log/suspend*.log. A state file which records which services were stopped and which modules unloaded is in /var/lib/suspend*-state.
Since software 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.
November 2004, Stefan Seyfried (seife@suse.de)
To use suspend with the binary only driver for NVidia graphics cards, you need to take some extra precautions. Note that this apparently does not work on all NVidia graphics chipsets, YMMV:
- download the NVidia driver with Yast Online Update, configure the card for 3D with sax2. You might need a fairly recent version of the NVidia driver, i tested with version 1.0.7167. Reading the nvidia-installer-howto from http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html is highly recommended.
- put the line Option "NvAgp" "1" in the Device section, under 'Vendor Name "NVidia"'
- do not load the vendor-agp module. To ensure this, remove any reference to the AGP modules from /etc/sysconfig/hardware:
# cd /etc/sysconfig/hardware # grep agp * hwcfg-vpid-8086-3340:MODULE_0='intel-agp'
now edit the file "hwcfg-vpid-8086-3340" (the one found with the grep command) and change "STARTMODE='auto'" to "STARTMODE='manual'". You might also want to remove the line "# HOTPLUG-FLAG: autocreated" to make this configuration persist future updates.
- reboot, make sure that the agp module is no longer loaded by running
# lsmod | grep agp
there should be no vendor-agp module (e.g. intel-agp, sis-agp,...) listed, only "agpgart".
AGP support will only work with chipsets, which are supported by the nvidia kernel module. Otherwise AGP support is simply disabled. Check this with "cat /proc/driver/nvidia/agp/status". If there is no line "Status: Enabled", then AGP support is not available. The graphics card will work without AGP, but performance will be bad.
Note that during suspend to disk, when the drivers get suspended, the display is switched off (and on notebooks this means also the backlight) but it is not switched back on when the drivers are resumed to write the image. This means that you will not see any progress indicator during suspend and if suspend fails (it should not :-) you will not see any error. There is not much we can do about this right now, just wait until the disk stops writing and the machine turns itself off. After resume from suspend, the driver is resumed correctly and the display and backlight is turned back on.
This was tested on a SONY VAIO PCG-GRT995MP and a Dell D800 with both suspend to disk and RAM. It did not work on an older Dell Inspiron 8200.
Have a lot of fun!
Stefan Seyfried (seife@suse.de).
May 2005
###############################################
# 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. |
Hello,
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 ;-)
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_bios calls the video BIOS during resume to initialize the video card. acpi_sleep=s3_mode calls the video BIOS during resume to reset the text mode. acpi_sleep=s3_bios,s3_mode combines the above.
Also if it "just does not work", it may be a good idea to try with the kernel parameter "vga=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. To make the whole thing a bit more "interesting", the vga=normal can (and probably has to) be combined with the acpi_sleep=... parameters from above.
Another possibility is to save and restore the VBE settings of the graphics card with the tool "vbetool". This is very 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.
A grub entry with those settings could look like this:
title SUSE LINUX 9.3 kernel (hd0,1)/boot/vmlinuz root=/dev/hda3 selinux=0 splash=silent resume=/dev/hda2 showopts vga=normal acpi_sleep=s3_bios initrd (hd0,1)/initrd
Note that i put the changed options after the "showopts" keyword, so i can easily see (and change) them at the boot prompt.
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.
The machines listed below are reported to be working or tested by us, they often need one of the "tricks" listed above which is noted along with them. As those machines are often available in different "generations" i tried to describe them a little closer with the information available from lspci or dmidecode, such as an exact model number or the exact type of the graphics card. If you have a similar graphics card, you might get by with the same "trick".
Machine specific "tricks":
Compaq Armada E500
no tricks needed, suspend2ram and standby works "out of the box".
(P3-700,ATI Rage Mobility P/M)
IBM Thinkpad R32
no tricks needed, "works out of the box".
(Type 2658-MMG)
IBM Thinkpad T20
no tricks needed, but console is corrupted after resume. vga=normal works better.
(Type 2647-44G, savage graphics)
IBM Thinkpad T41p
acpi_sleep=s3_bios,s3_mode
(Type 2373-W6M, ATI M10NT, [FireGL Mobility T2])
IBM Thinkpad X40
acpi_sleep=s3_bios,s3_mode
(Type 2371-7JG)
IBM Thinkpad 600e
no tricks needed, but after resume a switch from X to console and back is needed (or vbetool restore).
(Type 2645-5BG)
Toshiba Satellite 4080XCDT
acpi_sleep=s3_mode. suspend2ram and standby works
ASUS L2400D
acpi_sleep=s3_mode. suspend2ram and standby works.
Sharp PC-AR10
no tricks. The display backlight does not switch off,
but if you suspend via "lid close", the light is
turned off by the switch.
HP Omnibook 4150
no tricks, just works. standby works, too.
ACER Travelmate 803LCi
vga=normal, X server brings back the backlight
(ATI R250Lf)
ACER C300 Tablet PC
vesafb with "vbetool vbestate save / restore"
(i855 centrino)
FSC Amilo M7400 (i855)
vesafb with "vbetool vbestate save / restore"
SONY PCG-GRT995MP (nv)
no tricks, just works with the "nv" X driver. For
the binary NVidia driver, please read README.NVidia.
SONY VGN-FS115B
acpi_sleep=s3_bios,s3_mode.
If you used i855resolution during boot to get a fullscreen X display, you also need to use something like contrib/video_bios_suspend and contrib/video_bios_resume to re-patch the BIOS during resume before switching back to X. Some documentation is provided in those example scripts.
Often, the "acpi_sleep=s3_mode" is not strictly necessary since the X server will reset the text mode also, so it is sometimes more a "correctness issue" than a really needed fix.
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 suse-laptop mailinglist or directly.
Good luck and
Have a lot of fun... :-)
Stefan Seyfried (seife@suse.de)
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.
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/sysconfig/powersave/common set the scheme that should be used: AC_SCHEME="performance" BATTERY_SCHEME="powersave"
The schemes are config files in /etc/sysconfig/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/sysconfig/powersave/scheme_powersave) for available variables and syntax.
You can also override all general settings from any powewersave configuration file (/etc/sysconfig/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/sysconfig/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: power/sleep button and the lid closing/opening. battery levels are exceeded the power source changes (AC/Battery) temperature limits are reached the user requests a suspend/standby sleeping state the machine resumes from a suspend/standby sleeping state the daemon is stopped/started the user manually requests a power save policy, so called scheme change the CPU usage was under a certain level for a specific time (configurable in cpufreq conf file) Any non thermal, battery, ac or button ACPI event had happend
If an event happens, the configured actions for this event (file see above) 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) user can assign to each event.
Internal actions (name is reserved, scripts must not named like that) currently are:
ignore (do nothing)
throttle (throttle cpu(s) to value MAX_THROTTLING if ALLOW_THROTTLING is set to "yes" -> scheme configuration variables)
dethrottle (unthrottle cpu(s))
reread_cpu_capabilities (Trigger re-evaluation of usable CPU speeds. There are machines, that cannot run on full speed when on battery. This internal event causes a re- evaluation of which speeds are available. Usually only makes sense in acadapter.*-events).
suspend_to_disk (Trigger the global.suspend2disk event)
suspend_to_ram (Trigger the global.suspend2ram event)
standby (Trigger the global.standby event)
do_suspend_to_disk (Actually tell kernel to do a suspend-to-disk. Should only be used for global.suspend2disk event)
do_suspend_to_ram (see do_suspend_to_disk) do_standby (see do_suspend_to_disk)
External actions are simply executables (typically scripts) placed in /usr/lib/powersave/scripts. The name of the executable is the event name. Example: put EVENT_OTHER="debug_events" into /etc/sysconfig/powersave/events to debug the hotplug events on some ASUS notebooks (the asus_acpi module has to be loaded) and watch /var/log/messages.
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
Interfaces:
The Manager interface is connection oriented Interface. Clients have to connect (and send their capabilities) to the daemon.
-> client connection (message "connect" with the capabilities which can be handle by the connecting client).
-> return type: boolean (TRUE on successful connection, else: FALSE)
-> powersaved has to store the D-BUS sender string (e.g. ":1.5") of the "connect" message. Using this information gives the +possibility to track clients whether they died unexpectedly.
Depending on the amount of capabilities the client has, the daemon now knows
D-BUS Example:
signal sender=:1.5 -> dest=(null destination) interface=com.novell.powersave; member=connect
0 int32 "3"
11 corresponds to the capabilities CAPABILITY_NOTIFICATIONS and CAPABILITY_SCREENLOCK
D-BUS Example:
signal sender=:1.5 -> dest=(null destination) interface=com.novell.powersave; member=disconnect
-> According to the sender of the disconnect signal, the powersave daemon knows which capabilities are no longer available.
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"
-> according to its capabilities, the client has to set up matches in his filter function for the corresponding events triggered by the daemon.
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"
(Interface: com.novell.powersave.Request)
-> All requests do not have any parameters.
Powersave schemes
Return types:
Cpu frequency policy
Return type:
Battery status
Return type:
Ac adapter power
Return type:
Remaining percent of battery charge
Return type:
Remaining time untile battery is empty
Return type:
Remaining time untile battery is fully charges
Return type:
The current charging state
Return type:
If suspend to ram is allowed
Return type:
If suspend to disk is allowed
Return type:
If standby is allowed
Return type:
(Interface: com.novell.powersave.Action)
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
Set cpu policy to performance
Set cpu policy to powersave
Set cpu policy to dynamic
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 powersave_dbus.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.Action
Interface: com.novell.powersave.Action
Interface: com.novell.powersave.Action
Interface: com.novell.powersave.Action
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 client requests (normally from non-root users), 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:
Installation Instructions *************************
Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005 Free Software Foundation, Inc.
This file is free documentation; the Free Software Foundation gives unlimited permission to copy, distribute and modify it.
Basic Installation ==================
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses those values to create a `Makefile' in each directory of the package. It may also create one or more `.h' files containing system-dependent definitions. Finally, it creates a shell script `config.status' that you can run in the future to recreate the current configuration, and a file `config.log' containing compiler output (useful mainly for debugging `configure').
It can also use an optional file (typically called `config.cache' and enabled with `–cache-file=config.cache' or simply `-C') that saves the results of its tests to speed up reconfiguring. (Caching is disabled by default to prevent problems with accidental use of stale cache files.)
If you need to do unusual things to compile the package, please try to figure out how `configure' could check whether to do them, and mail diffs or instructions to the address given in the `README' so they can be considered for the next release. If you are using the cache, and at some point `config.cache' contains results you don't want to keep, you may remove or edit it.
The file `configure.ac' (or `configure.in') is used to create `configure' by a program called `autoconf'. You only need `configure.ac' if you want to change it or regenerate `configure' using a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type `./configure' to configure the package for your system. If you're using `csh' on an old version of System V, you might need to type `sh ./configure' instead to prevent `csh' from trying to execute `configure' itself.
Running `configure' takes awhile. While running, it prints some messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Optionally, type `make check' to run any self-tests that come with the package.
4. Type `make install' to install the programs and any data files and documentation.
5. You can remove the program binaries and object files from the source code directory by typing `make clean'. To also remove the files that `configure' created (so you can compile the package for a different kind of computer), type `make distclean'. There is also a `make maintainer-clean' target, but that is intended mainly for the package's developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution.
Compilers and Options =====================
Some systems require unusual options for compilation or linking that the `configure' script does not know about. Run `./configure –help' for details on some of the pertinent environment variables.
You can give `configure' initial values for configuration parameters by setting variables in the command line or in the environment. Here is an example:
./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
*Note Defining Variables::, for more details.
Compiling For Multiple Architectures ====================================
You can compile the package for more than one kind of computer at the same time, by placing the object files for each architecture in their own directory. To do this, you must use a version of `make' that supports the `VPATH' variable, such as GNU `make'. `cd' to the directory where you want the object files and executables to go and run the `configure' script. `configure' automatically checks for the source code in the directory that `configure' is in and in `..'.
If you have to use a `make' that does not support the `VPATH' variable, you have to compile the package for one architecture at a time in the source code directory. After you have installed the package for one architecture, use `make distclean' before reconfiguring for another architecture.
Installation Names ==================
By default, `make install' installs the package's commands under `/usr/local/bin', include files under `/usr/local/include', etc. You can specify an installation prefix other than `/usr/local' by giving `configure' the option `–prefix=PREFIX'.
You can specify separate installation prefixes for architecture-specific files and architecture-independent files. If you pass the option `–exec-prefix=PREFIX' to `configure', the package uses PREFIX as the prefix for installing programs and libraries. Documentation and other data files still use the regular prefix.
In addition, if you use an unusual directory layout you can give options like `–bindir=DIR' to specify different values for particular kinds of files. Run `configure –help' for a list of the directories you can set and what kinds of files go in them.
If the package supports it, you can cause programs to be installed with an extra prefix or suffix on their names by giving `configure' the option `–program-prefix=PREFIX' or `–program-suffix=SUFFIX'.
Optional Features =================
Some packages pay attention to `–enable-FEATURE' options to `configure', where FEATURE indicates an optional part of the package. They may also pay attention to `–with-PACKAGE' options, where PACKAGE is something like `gnu-as' or `x' (for the X Window System). The `README' should mention any `–enable-' and `–with-' options that the package recognizes.
For packages that use the X Window System, `configure' can usually find the X include and library files automatically, but if it doesn't, you can use the `configure' options `–x-includes=DIR' and `–x-libraries=DIR' to specify their locations.
Specifying the System Type ==========================
There may be some features `configure' cannot figure out automatically, but needs to determine by the type of machine the package will run on. Usually, assuming the package is built to be run on the _same_ architectures, `configure' can figure that out, but if it prints a message saying it cannot guess the machine type, give it the `–build=TYPE' option. TYPE can either be a short name for the system type, such as `sun4', or a canonical name which has the form:
CPU-COMPANY-SYSTEM
where SYSTEM can have one of these forms:
OS KERNEL-OS
See the file `config.sub' for the possible values of each field. If `config.sub' isn't included in this package, then this package doesn't need to know the machine type.
If you are _building_ compiler tools for cross-compiling, you should use the option `–target=TYPE' to select the type of system they will produce code for.
If you want to _use_ a cross compiler, that generates code for a platform different from the build platform, you should specify the "host" platform (i.e., that on which the generated programs will eventually be run) with `–host=TYPE'.
Sharing Defaults ================
If you want to set default values for `configure' scripts to share, you can create a site shell script called `config.site' that gives default values for variables like `CC', `cache_file', and `prefix'. `configure' looks for `PREFIX/share/config.site' if it exists, then `PREFIX/etc/config.site' if it exists. Or, you can set the `CONFIG_SITE' environment variable to the location of the site script. A warning: not all `configure' scripts look for a site script.
Defining Variables ==================
Variables not defined in a site shell script can be set in the environment passed to `configure'. However, some packages may run configure again during the build, and the customized values of these variables may be lost. In order to avoid this problem, you should set them in the `configure' command line, using `VAR=value'. For example:
./configure CC=/usr/local2/bin/gcc
causes the specified `gcc' to be used as the C compiler (unless it is overridden in the site shell script). Here is a another example:
/bin/bash ./configure CONFIG_SHELL=/bin/bash
Here the `CONFIG_SHELL=/bin/bash' operand causes subsequent configuration-related scripts to be executed by `/bin/bash'.
`configure' Invocation ======================
`configure' recognizes the following options to control how it operates.
`–help' `-h' Print a summary of the options to `configure', and exit.
`–version' `-V' Print the version of Autoconf used to generate the `configure' script, and exit.
`–cache-file=FILE' Enable the cache: use and save the results of the tests in FILE, traditionally `config.cache'. FILE defaults to `/dev/null' to disable caching.
`–config-cache' `-C' Alias for `–cache-file=config.cache'.
`–quiet' `–silent' `-q' Do not print messages saying which checks are being made. To suppress all normal output, redirect it to `/dev/null' (any error messages will still be shown).
`–srcdir=DIR' Look for the package's source code in directory DIR. Usually `configure' can determine that directory automatically.
`configure' also accepts some other, not widely useful, options. Run `configure –help' for more details.
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. I'll integrate them into CVS and will 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 graphical KDE front-end to powersave. Works reliable and stable and got extensive testing. Perfect for end-users.
It supports switching between schemes, triggering suspend, shows the current battery level and warns if battery limits are sub-ceeded. It also offers configuration of X-based power functions such as DPMS and screensaver and some more.
The KPowersave daemon is currently maintained by Danny Kukawka (danny.kukawka@web.de)
The graphical Window Maker front-end. Similar functionalities as KPowersave, but slightly restricted due the fact that it is a Window Maker applet.
The WMPowersave client is currently maintained by Holger Macht, who also implemented the client connection stuff in the powersave daemon (holger@homac.de).
Let the end-user configure most of the variables in /etc/sysconfig/powersave/* graphically. Unfortunately SUSE only of course.
A small hack from Stefan Seyfried. Get the latest CVS snapshot from http://forge.novell.com/modules/xfmod/cvs/cvsbrowse.php/powersave/gkrellm-powersave/
The KPowersave and WMPowersave project are also hosted on the powersave project's sites at http://sourceforge.net/projects/powersave and http://forge.novell.com/modules/xfmod/project/?powersave
# Author Thomas Renninger # Stefan Seyfried
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.
These implementations are planned for the near future (any help is appreciated):
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/sysconfig/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="" in the /etc/sysconfig/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/sysconfig/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
echo XXX >/proc/acpi/debug_level
cat /proc/acpi/debug_level
echo 0x1F >/proc/acpi/debug_level
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 CVS can be found at http://forge.novell.com/modules/xfmod/project/?powersave. See the section Get the CVS Sources at Compiling. Modify/Add files in the docs directory. Do a: makinfo –html powersave.tex in the docs directory and see whether you have some errors (you need to escapce e.g. @ with @@). Send us the "diff -urN" of your modifications in the docs dir and we will include it.
If you like to and prove some ambitions your welcome to join and help extending the powersave daemon with extended rights on the sourceforge/novellforge powersave project.
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 acpi-devel List:
Acpi-devel@lists.sourceforge.net at https://lists.sourceforge.net/lists/listinfo/acpi-devel
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 CVS)
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:
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 find the newest ACPI specification here:
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