Problem with high power drain in ACPI sleep

From ThinkWiki
Revision as of 12:36, 10 May 2005 by (Talk)
Jump to: navigation, search

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

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.

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).
  • 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 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 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-EHG
    • 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
  • T41
    • 2379-DJU
    • 2373-9HU
    • 2373-4FG
    • 2373-4PG
    • 2373-2FG
    • 2373-6U4
    • 2373-7JU
  • T41p
    • 2373-9FU
  • T42
  • X21

Affected Operating Systems

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


  • The cause of the problem is not really clear, yet.
  • 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.)
  • There is a interesting discussion taking place in the OSDL Bugzilla.

Update: it seems that the most significant difference can be made by properly turning off the video chip.


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.

For Fedora Core there's are precompiled patched kernels (2.6.11-rc2 based) available:

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.

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.

for other models

Nothing yet.