Difference between revisions of "Problem with high power drain in ACPI sleep"

From ThinkWiki
Jump to: navigation, search
(For Thinkpads with Radeon graphic driver: Note about loading radeonfb in FC4)
Line 2: Line 2:
  
 
==Problem description==
 
==Problem description==
Several people realised that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.
+
Several people realized that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.
  
 
==Affected Models==
 
==Affected Models==
 +
 
*Different symptoms have been reported for different models. In some models the origin of the power drain is obvious ([[Problem with LCD backlight remaining on during ACPI sleep|backlight on during suspend]]), in other models there is no obvious reason.
 
*Different symptoms have been reported for different models. In some models the origin of the power drain is obvious ([[Problem with LCD backlight remaining on during ACPI sleep|backlight on during suspend]]), in other models there is no obvious reason.
 +
 
*On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.
 
*On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.
*The T4x thinkpad series (T40, T40p, T41, T41p, T42, T42p, T43, T43p) suspends to ram just fine, and there are no components that are obviously left powered up. The [[UltraBay]] and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF).
+
 
*One thing to keep in mind, though, is that some models only suffer this problem with certain software. For example, my T40 (2374-94U) has the high power drain issue with the stock Fedora Core 3. If I use one of the more recent kernels from [http://www.sas.upenn.edu/~vbraun/computing/T41/kernel.html Volker Braun's T-41 site], everything (suspend-to-RAM, suspend-to-disk) works just fine and my battery life seems much better than APM. In other words, just because you see this problem with your ThinkPad with your current software does not mean that your ThinkPad will doomed to always be affected. There are similar solutions for Debian-based systems too.
+
*The T4x Thinkpad series (T40, T40p, T41, T41p, T42, T42p, T43, T43p) suspends to ram just fine, and there are no components that are obviously left powered up. The [[UltraBay]] and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF).
 +
 
 +
*This is a driver problem and can be fixed in software. For the T4x series, there is a fix available but it has not yet made its way into the official kernel (as of linux 2.6.12).
  
 
The following table gives an overview of the models suffering from the mysterious power drain. To find out about your model, you may use the following [[ACPI sleep power drain test script | script]]. It creates a file <tt>/var/log/battery.log</tt> which will tell you if you are affected or not.
 
The following table gives an overview of the models suffering from the mysterious power drain. To find out about your model, you may use the following [[ACPI sleep power drain test script | script]]. It creates a file <tt>/var/log/battery.log</tt> which will tell you if you are affected or not.
Line 97: Line 101:
  
 
==Status==
 
==Status==
*The cause of the problem is not really clear, yet.
+
*The cause of the mysterious power drain is the radeon GPU, which requires extra steps to suspend properly. Unfortunately, this fix might break non-Thinkpad machines and therefore is not yet in the official kernel sources.
  
*A faulty DSDT might be responsible for the phenomenon. The thinkpad T4x DSDT has a few small bugs, none of which should cause the extra power drain. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)
+
*The official bugzilla entry for the radeon suspend issue is in the [http://bugme.osdl.org/show_bug.cgi?id=3022 OSDL Bugzilla]. There you can find a patch which will solve the power drain issue.
  
*There is a interesting discussion taking place in the [http://bugme.osdl.org/show_bug.cgi?id=3022 OSDL Bugzilla].
+
{{WARN|This solution enables doing suspend-to-D2 on non-PPC-machines, which is not properly documented! Be careful and have a look at the discussion for kernel bug 3022 (see above) before applying the patch. By default, the patch enables the suspend-to-D2 only on machines where it is know to work. This behaviour can be overridden with a module option.}}
  
Update: it seems that the most significant difference can be made by properly turning off the video chip.
+
*Most certainly, the DSDT is not at fault. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)
 +
 
 +
*Some additional power savings can be achieved by turning off the wake-on-lan (<tt>ethtool -s eth0 wol d</tt>). The power drain of the wol feature is far smaller than the radeon bug, but can be noticeable.
  
 
==Solutions==
 
==Solutions==
Line 109: Line 115:
 
A proposed solution is to remove the CONFIG_PPC_PMAC condition for enabling D2 sleep in drivers/video/aty/radeon_pm.c as discussed in [http://bugme.osdl.org/show_bug.cgi?id=3022 kernel bug 3022]. There you can also find patches doing this. The patches divide into unconditional ones like [http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/patch-2.6.11-rc2-radeonfb-D2.patch.bz2 this one for 2.6.11-rc2] and conditional ones. The conditional ones only do D2 on models where it has been reported to work, the unconditional ones force D2 sleep on every model and you might experience hangs on resume with those.
 
A proposed solution is to remove the CONFIG_PPC_PMAC condition for enabling D2 sleep in drivers/video/aty/radeon_pm.c as discussed in [http://bugme.osdl.org/show_bug.cgi?id=3022 kernel bug 3022]. There you can also find patches doing this. The patches divide into unconditional ones like [http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/patch-2.6.11-rc2-radeonfb-D2.patch.bz2 this one for 2.6.11-rc2] and conditional ones. The conditional ones only do D2 on models where it has been reported to work, the unconditional ones force D2 sleep on every model and you might experience hangs on resume with those.
  
For [[:Category:Fedora Core | Fedora Core]] there's are precompiled patched kernels (2.6.11-rc2 based) available:
+
===Fedora Core 4 official kernel===
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/kernel-DANGEROUS-T4x-2.6.11-8.i386.rpm kernel with unconditional patch applied]
+
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/kernel-T4x-2.6.11-8.i386.rpm kernel with conditional patch applied].
+
  
If you try, please send the result (hang yes/no, battery drain yes/no) with the precise model number (for example, I have a IBM thinkpad T41 2379-DJU) to <tt>vbraun at physics dot upenn dot edu</tt>, it would be nice if your subject line would include "RADEONFB:" to make sure that I do not miss any emails.
+
Note that you must actually load the <tt>radeonfb</tt> kernel module, for the sleep patches to have any effect; this should be done ''before'' you start the X server. In [[:Category:Fedora Core | Fedora Core 4]] at least, you can try out the effect by including the module parameter <tt>radeon_force_sleep=1</tt> in the <tt>modprobe</tt> command.
  
{{WARN|This solution enables doing suspend-to-D2 on non-PPC-machines, which is not tested at all and supposed to be the wrong thing to do! Be careful and have a look at the discussion for kernel bug 3022 (see above) before applying the patch.}}
+
===Fedora Core 3/4 custom kernel===
  
Note that you must actually load the <tt>radeonfb</tt> kernel module, for the sleep patches to have any effect; this should be done ''before'' you start the X server. In [[:Category:Fedora Core | Fedora Core 4]] at least, you can try out the effect by including the module parameter <tt>radeon_force_sleep=1</tt> in the <tt>modprobe</tt> command.
+
For [[:Category:Fedora Core | Fedora Core]] there are precompiled patched kernels [http://www.sas.upenn.edu/~vbraun/computing/T41/kernel.html available]:
 +
 
 +
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/i386/kernel-T4x-2.6.11.11-26.i386.rpm linux 2.6.11 for Fedora Core 3]
 +
 
 +
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/i386/kernel-T4x-2.6.12.2-2.i386.rpm linux 2.6.12 for Fedora Core 4]
 +
 
 +
These kernels contain additional thinkpad-related patches, including software suspend2 and trackpoint support. Suspend to disk and suspend to ram should work with them. If your thinkpad model is not yet whitelisted in the patch, you might have to enable the radeon fix by including the parameter <tt>video=radeonfb:radeon_force_sleep=1</tt> on the kernel command line.
 +
 
 +
If you try, please send the result (hang yes/no, battery drain yes/no) with the precise model number (for example, I have a IBM thinkpad T41 2379-DJU) to <tt>vbraun at physics dot upenn dot edu</tt>, it would be nice if your subject line would include "RADEONFB:" to make sure that I do not miss any emails.
  
===for other models===
+
===for other models without radeon graphics===
 
Nothing yet.
 
Nothing yet.

Revision as of 19:31, 2 July 2005

Information about the problem of too high power drain in ACPI sleep mode.

Problem description

Several people realized that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.

Affected Models

  • Different symptoms have been reported for different models. In some models the origin of the power drain is obvious (backlight on during suspend), in other models there is no obvious reason.
  • On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.
  • The T4x Thinkpad series (T40, T40p, T41, T41p, T42, T42p, T43, T43p) suspends to ram just fine, and there are no components that are obviously left powered up. The UltraBay and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF).
  • This is a driver problem and can be fixed in software. For the T4x series, there is a fix available but it has not yet made its way into the official kernel (as of linux 2.6.12).

The following table gives an overview of the models suffering from the mysterious power drain. To find out about your model, you may use the following script. It creates a file /var/log/battery.log which will tell you if you are affected or not.

affected models unaffected models
  • R40
    • 2722-5MG
    • 2722-B3G
    • 2897-GWU
  • R50
    • 1829-7RG
    • 1829-6DM
    • 1836-3SU
  • R51
    • 1829-9MG
    • 1829-EHG
    • 1830-DG4
    • 1836-Q6U
  • T23
    • 2647-???
  • T30
    • 2366-81A
    • 2366-97U
  • T40
    • 2373-MU3
    • 2373-82U
    • 2373-92U
    • 2373-22G
    • 2373-19G
    • 2373-A1U
  • T40p
    • 2373-G1U
    • 2373-G3U
    • 2373-G3G
    • 2373-G1G
    • 2373-G5G
  • T41
    • 2379-DJU
    • 2373-9HU
    • 2373-4FG
    • 2373-4PG
    • 2373-1FG
    • 2373-2FG
    • 2373-6U4
    • 2373-7JU
    • 2373-CY0
    • 2373-TG5
  • T41p
    • 2373-9FU
  • T42
  • X21

Affected Operating Systems

  • Linux, all flavours.
  • Windows, for some models as well (only when using non-IBM drivers).
  • FreeBSD (on the A22M)

Status

  • The cause of the mysterious power drain is the radeon GPU, which requires extra steps to suspend properly. Unfortunately, this fix might break non-Thinkpad machines and therefore is not yet in the official kernel sources.
  • The official bugzilla entry for the radeon suspend issue is in the OSDL Bugzilla. There you can find a patch which will solve the power drain issue.
ATTENTION!
This solution enables doing suspend-to-D2 on non-PPC-machines, which is not properly documented! Be careful and have a look at the discussion for kernel bug 3022 (see above) before applying the patch. By default, the patch enables the suspend-to-D2 only on machines where it is know to work. This behaviour can be overridden with a module option.
  • Most certainly, the DSDT is not at fault. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)
  • Some additional power savings can be achieved by turning off the wake-on-lan (ethtool -s eth0 wol d). The power drain of the wol feature is far smaller than the radeon bug, but can be noticeable.

Solutions

For Thinkpads with Radeon graphic driver

A proposed solution is to remove the CONFIG_PPC_PMAC condition for enabling D2 sleep in drivers/video/aty/radeon_pm.c as discussed in kernel bug 3022. There you can also find patches doing this. The patches divide into unconditional ones like this one for 2.6.11-rc2 and conditional ones. The conditional ones only do D2 on models where it has been reported to work, the unconditional ones force D2 sleep on every model and you might experience hangs on resume with those.

Fedora Core 4 official kernel

Note that you must actually load the radeonfb kernel module, for the sleep patches to have any effect; this should be done before you start the X server. In Fedora Core 4 at least, you can try out the effect by including the module parameter radeon_force_sleep=1 in the modprobe command.

Fedora Core 3/4 custom kernel

For Fedora Core there are precompiled patched kernels available:

These kernels contain additional thinkpad-related patches, including software suspend2 and trackpoint support. Suspend to disk and suspend to ram should work with them. If your thinkpad model is not yet whitelisted in the patch, you might have to enable the radeon fix by including the parameter video=radeonfb:radeon_force_sleep=1 on the kernel command line.

If you try, please send the result (hang yes/no, battery drain yes/no) with the precise model number (for example, I have a IBM thinkpad T41 2379-DJU) to vbraun at physics dot upenn dot edu, it would be nice if your subject line would include "RADEONFB:" to make sure that I do not miss any emails.

for other models without radeon graphics

Nothing yet.