All error messages and alerts are logged in the file
/var/log/messages. If you cannot find the needed
information, increase the verbosity of the messages of powersave using
DEBUG in the file
/etc/sysconfig/powersave/common. Increase the value
of the variable to 7 or even 15 and
restart the daemon. The more detailed error messages in
/var/log/messages should help you to find the error.
The following sections cover the most common problems with powersave and
the different sleep modes.
If you experience problems with ACPI, use the command
dmesg|grep -i acpi to search the
output of dmesg for ACPI-specific messages. A BIOS
update may be required to resolve the problem. Go to the home page of
your laptop manufacturer, look for an updated BIOS version, and install
it. Ask the manufacturer to comply with the latest ACPI specification.
If the errors persist after the BIOS update, proceed as follows to
replace the faulty DSDT table in your BIOS with an updated DSDT:
Download the DSDT for your system from
http://acpi.sourceforge.net/dsdt/index.php.
Check if the file is decompressed and compiled as shown by the file
extension .aml (ACPI machine language). If this is
the case, continue with step 3.
If the file extension of the downloaded table is
.asl (ACPI source language), compile it with iasl
(package acpica). Enter the
command iasl -sa file.asl.
Copy the file DSDT.aml to any location
(/etc/DSDT.aml is recommended). Edit
/etc/sysconfig/kernel and adapt the path to the
DSDT file accordingly. Start mkinitrd (package
mkinitrd). Whenever
you install the kernel and use mkinitrd to create
an initrd, the modified DSDT is integrated and
loaded when the system is booted.
Refer to the kernel sources
(kernel-source) to see if your
processor is supported. You may need a special kernel module or module
option to activate CPU frequency control. This information is available
in /usr/src/linux/Documentation/cpu-freq/*.
ACPI systems may have problems with suspend and standby due to a faulty DSDT implementation (BIOS). If this is the case, update the BIOS.
When the system tries to unload faulty modules, the system is arrested
or the suspend event is not triggered. The same can also happen if you
do not unload modules or stop services that prevent a successful
suspend. In both cases, try to identify the faulty module that prevented
the sleep mode. The log file
/var/log/pm-suspend.log contains detailed
information about what is going on and where possible errors are. Modify
the SUSPEND_MODULES variable in
/usr/lib/pm-utils/defaults to unload problematic
modules prior to a suspend or standby.
Refer to http://en.opensuse.org/Pm-utils and http://en.opensuse.org/S2ram to get more detailed information on how to modify the suspend and resume process.