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

From ThinkWiki
Jump to: navigation, search
m (→‎Affected Models)
(Added 2373-3kg to list of affected T41 (I tested this machine: after the patch was applied the power drain issue seems to be gone))
Line 57: Line 57:
 
* {{T41}}
 
* {{T41}}
 
**2379-DJU
 
**2379-DJU
 +
**2373-3KG
 
**2373-9HU
 
**2373-9HU
 
**2373-4FG
 
**2373-4FG

Revision as of 15:53, 25 March 2006

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
    • 2373-FWG
    • 2374-ZEP
    • 2373-F2G
    • 2373-VUW
    • 2373-6ZG
  • X21
    • 2662-BSG
  • X32
    • 2884-A3U
  • 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. This fix has not yet made its way into the official kernel (as of linux 2.6.12).

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)

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 known 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 chips

You must use a patched version of the radeon frame buffer, even if you are only interested in using the X window system. This modified radeon frame buffer then suspends the radeon chip correctly during ACPI sleep. This patch is not yet in the official (kernel.org) kernels.

The patch contains a list of ThinkPads where it is known to work, and by default only activates on these machines. If you think that your computer would profit from the patch as well, you can force it by including the module parameter radeon_force_sleep=1. If it doesn't work this can result in system hangs.

Technical Background

The patch removes the CONFIG_PPC_PMAC condition for enabling D2 sleep in drivers/video/aty/radeon_pm.c as discussed in kernel bug 3022.

Fedora Core

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

There are precompiled patched kernels available as well, that do not need an initrd modification:

These kernels contain additional ThinkPad-related patches, including Software Suspend 2 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 (i.e. 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.

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 radeon_force_sleep=1
  • Finally, resume X: # init 5
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:radeon_force_sleep=1.

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.

Another possible solution

It is possible that radeontool will help some people with this case. (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).

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.

Retrieved from "https://www.thinkwiki.org/w/index.php?title=Problem_with_high_power_drain_in_ACPI_sleep&oldid=21124"