Problem with high power drain in ACPI sleep

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

affected models

unaffected models

R32 2658-BQG R40 2722-3GG 2722-5MG 2722-B3G 2722-CDG 2897-GWU 2722-6YU 2722-CDG R50 1829-7RG 1829-6DM 1836-3SU R51 1829-9MG 1829-EHG 1829-R6G 1830-DG4 1836-Q6U T23 2647-??? T30 2366-81A 2366-97U 2366-FBU 2366-96G T40 2373-19G 2373-22G 2373-42G 2373-75G 2373-82U 2373-92U 2373-A1U 2373-MU3 T40p 2373-G1U 2373-G3U 2373-G3G 2373-G1G 2373-G5G T41 2379-DJU 2373-3KG 2373-9HU 2373-4FG 2373-4PG 2373-1FG 2373-2FG 2373-2GG 2373-6U4 2373-7JU 2373-CY0 2373-TG5 2373-3HM 2373-4GU T41p 2373-9FU T42 2373-C19 2373-CTO 2378-DTU 2378-DUU 2378-XXE 2378-R4U 2373-FWG 2374-ZEP 2373-F2G 2373-JTU 2373-VUW 2373-6ZG X21 2662-BSG X32 2884-A3U X41 Tablet 1869-5CU

A22m 2628 A31 2652-D5G R50p R52 1858-6MM T41 2373-GEU T41p 2373-GKG 2373-GGG 2373-GHG T42 2373-M1G 2373-WBZ 2373-F7G 2378-DXU 2378-FVU 2378-RTU 2378-RRU T42p 2373-HTG 2373-W6M 2373-GTG 2373-GXG 2373-KXM T43 2668-W12 T43p 2668-G2G X40 2371

• 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 and other Radeon based models suspend 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). For these models the higher power drain is caused by a driver problem and can be fixed in software. Starting with linux 2.6.18 this fix is in the official kernel.

The table on the right 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 Operating Systems

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

Radeon GPU not powered off

A frequent cause of the mysterious power drain is the Radeon GPU, which requires extra steps to suspend properly. We identified affected thinkpads, and radeonfb activates the workaround on those models automatically (starting with linux kernel 2.6.18).

Status

• The official bugzilla entry for the radeon suspend issue is in the OSDL Bugzilla. There you can find the above-mentioned patch for older kernel versions. The patch removes the CONFIG_PPC_PMAC condition for enabling D2 sleep in drivers/video/aty/radeon_pm.c. If you suspect that this patch makes things worse, you can disable it by the kernel parameter video=radeonfb:ignore_devlist. Similarly, if the patch is not automatically activated on your notebook you can force it by video=radeonfb:force_sleep. In case that improves your sleep, please leave a note in the bugzilla including the output of # lspci -d "1002:*" -vn. See also the linux-thinkpad ML post requesting this information for more information.

• 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.)

Solutions

You must use a recent (or patched) version of the radeonfb driver, even if you are only interested in using the X window system. The radeon frame buffer suspends the radeon chip correctly during ACPI sleep. Starting with linux 2.6.18, this patch is in the official (kernel.org) kernels.

If the patch is known to work on your notebook, it is automatically enabled. If you think that your computer would profit from the patch as well, you can force it by including the module parameter video=radeonfb:force_sleep. If it does not work this can result in system hangs.

Alas, in many cases radeonfb cannot coexist with the radeon X.org driver (causing corrupted rendering and hangs). Using the Option "UseFBDev" "True" of radeon may help, but this is incompatible with radeon's mergedfb mode. A "GPU device layer" architecture which may, one day, resolve this was proposed by Dave Airlie here and here.

Help needed

Is there any fully working solution?

Fedora Core

• Fedora Core 6: Ships with kernel >= 2.6.18, only needs initrd (see below).
• Fedora Core 5: The latest kernel from updates (2.6.18-1.2200.fc5) seems to actually fix this issue, you only have to make custom initrd because the default one does not contain radeonfb.
• Fedora Core 4: Fedora ships a patched radeon frame buffer (radeonfb.ko), but you must enable it yourself. Fedora compiles it as a module rather than including it in the kernel, therefore you cannot activate it at boot time without a custom initrd. You must arrange for the module to be loaded before X starts (for example, using an init script).
• Fedora Core 3: this is also true for updated kernels (at least for kernel-2.6.12-1.1376_FC3) but not for the initially shipped version.

testing radeonfb without changing initrd

If you want to try the radeon frame buffer, you can enable it as follows:

• First, switch to a console (CtrlAltF1) and log in as root.
• Stop X: # init 3
• Now you can load the module: # modprobe radeonfb force_sleep=1
• Finally, resume X: # init 5

Gentoo

After installing the patch on Gentoo (it works fine with gentoo-sources: # cd /usr/src/linux/drivers/video/aty, and execute # patch -p4 < <patchname>, then recompile the kernel), one needs to add video=radeonfb:force_sleep to the kernel parameters.

including radeonfb into your initrd

As an alternative you can build your customized initrd. This is as simple as running

# mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> `uname -r`

and replacing the initrd in /boot/grub/grub.conf with your new one. You also need to add the kernel command line argument video=radeonfb:force_sleep.

With FC6 and KDE I had to:

• Login as root
• Enter the command as # mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> <kernel version>

e.g. # mkinitrd --with=radeonfb /boot/initrd-2.6.18-1.2798.fc6-my.img 2.6.18-1.2798.fc6

And the kernel command line argument was added to /etc/sysconfig/grub.

Backlight staying on

It is possible that radeontool will help some people if the backlight stays on. (simply run "radeontool light off" before suspend and "radeontool light on" after resume). A radeontool patch for freebsd is here: http://www.init-main.com/radeontool.patch (by Takanori Watanabe).

Notes for gnome-power-manager

If you suspend from Gnome and need to run radeontool to turn the backlight off you need to find the suspend script for HAL. In Ubuntu, the scripts are located in /usr/share/hal/scripts/. Add the following the script "hal-system-power-suspend":

chvt 1
radeontool light off

And in the resume script ("restore-after-standby"):

radeontool light on
chvt 7

This worked for me. YMMV. Etnoy 16:27, 9 November 2006 (CET)

For models without Radeon graphics

The Problem seems to be solved when you use the vbetool to turn the LCD off before suspending ...

# vbetool dpms off

and turning it on afterwards again...

# vbetool dpms on

You have to change to a normal console before turning the LCD off. Additionally you have to deactivate the Wake-On-Lan feature like mentioned above ...

# ethtool -s eth0 wol d

With these commands used together the "testing script" reports no high power drain while suspending.

Other problems causing the power drain

On my R51 using Gentoo Linux, the high power drain was not caused by the graphics adaptor but by several components not powered down properly before putting the Thinkpad into S3.

If the above did not help you, this might do:

Walk through

/sys/devices/*/*/power/state

and try to disable each of it, every time checking the power drain. (See linux/Documentation/power/devices.txt for values to write into the state-files. 3 should be the value you want to try) Do the same for other components (Like the Ultrabay, etc.). Please add your experiences here.

R51: Ultrabay and networking

On my system, ultrabay and networking light were still on while in S3. So were the devices theirselves.

echo -n eject > /proc/acpi/ibm/bay     # Disable ultrabay
ethtool -s eth0 wol d                  # Disable Wake-On-Lan (And so the eth-adaptor)
echo mem > /sys/power/state            # Sleep

For me, this lowered the power drain from >700mW to 338 mW.

USB

My initial testing of a T43 (2669-model) revealed no power drain issues. However, after several rounds of BIOS and kernel upgrades I have discovered that the power drain has risen to >700mWh. Having tested things a bit, I have discoved that removing ehci_hcd module solved the high power drain. This is a T43 laptop, with kernel 2.6.17-r5 and BIOS 1.28/EC 1.06. For me, issuing # modprobe -r ehci_hcd before going to sleep and reloading the module (# modprobe ehci_hcd) after waking up dropped the power drain down to 277mWh in suspend2ram, which seems fair. The unloading/reloading can be put into the suitable ACPI script called to suspend the laptop.

Wake-on-LAN

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.