IBM ThinkPad T42 uses excessive amount of battery in ACPI suspend mode

[Tim Hull]

I am using an IBM ThinkPad T42, and I configured it for ACPI suspend by editing the
ACPI shell scripts (to shut down hotplug,suspend,and re-enable hotplug on
resume). It works fine (except
for occasional flakiness involving ipw2200), however, it is consuming power very
fast in suspend as
compared to on Windows XP. To be more precise, it consumes about 15% of the
standard battery per hour in suspend (about 1/3 to 1/2 of the battery power used
outside of suspend mode).

[Matthew Garrett (mjg59)]

Yeah, this has been reported before with the IBM T series. The main thing that
springs to mind is that some of the devices aren't being set to D3 correctly -
it's probably worth taking a look at the kernel PCI suspend code, and checking
that it actually does this (my recollection is that it doesn't, which probably
isn't the best way of doing it - on the other hand, blindly setting everything
to D3 probably won't help). I'll see what it does, and if my hunch is correct
I'll generate a patch.

[Matthew Garrett (mjg59)]

Could you possibly attach the output of the lspci command?

[Tim Hull (thully-arbornet)]

Created an attachment (id=717)
lspci output

[Tim Hull (thully-arbornet)]

Remember - this happens in just ACPI, not APM, mode.
In APM mode, the system suspends while using very little power.

[Tim Hull (thully-arbornet)]

Created an attachment (id=906)
IBM ThinkPad T42 DSDT file

Uploading DSDT file.

[Tim Hull (thully-arbornet)]

This still is happening for me - any way this could get fixed in Hoary?
Also, in the latest kernels for Hoary (for the last week) my battery life
outside of suspend has decreased about 10% -
could that be looked into as well as this issue?

[Tim Hull (thully-arbornet)]

There is now a preliminary fix to this issue, but it needs work and integration.
This involves using a utility to power down the video card on suspend and power
up on resume.
You will need to install pciutils-dev, and then download the file at
http://www.srcf.ucam.org/~mjg59/radeon/radeontool-1.5-mjg.tar.gz
Compile the code in this tarball, and put the resulting executable "radeontool"
in a place in the path, like /usr/local/bin
Add, to the end of /etc/acpi/prepare.sh:
radeontool power off
Add, to the beginning of /etc/acpi/resume.sh (but after the line beginning in #)
radeontool power on

This will take care of the problem, but needs integration work (so that it is
only used when the problem exists).

[Tim Hull (thully-arbornet)]

More info on this can be found at http://bugzilla.kernel.org/show_bug.cgi?id=3022

Note that this fix is experimental and may not work on all systems affected by
this bug yet.
Also, if you are having trouble getting radeontool to execute from the suspend
scripts, specify the full
path in addition to the command, like this:
/usr/local/bin/radeontool power off

[Tim Hull (thully-arbornet)]

Correction 2: radeontool arguments are different than listed above, hence the
above fix does not work.
Instead, add
radeontool dac off
radeontool light off
to the end of /etc/acpi/prepare.sh and
radeontool light on
radeontool dac on
right after the line beginning with # at the beginning of /etc/acpi/resume.sh

[Matthew Garrett (mjg59)]

No, don't do that. It won't work. What makes you think radeontool power off
doesn't work?

(Though I have just noticed it isn't listed in the set of options - it appears
to work fine)

[Tim Hull (thully-arbornet)]

It just dumped a list of valid options when I tried to do it...
Because of this, I thought I'd try using the listed options - but as you state,
those don't work.

[Tim Hull (thully-arbornet)]

Apparently the radeontool tarball I had was messed up (and didn't have the right
version of radeontool) so re-download radeontool and
try the original instructions as follows (it should work):

here is now a preliminary fix to this issue, but it needs work and integration.
This involves using a utility to power down the video card on suspend and power
up on resume.
You will need to install pciutils-dev, and then download the file at
http://www.srcf.ucam.org/~mjg59/radeon/radeontool-1.5-mjg.tar.gz
Compile the code in this tarball, and put the resulting executable "radeontool"
in a place in the path, like /usr/local/bin
Add, to the end of /etc/acpi/prepare.sh:
radeontool power off
Add, to the beginning of /etc/acpi/resume.sh (but after the line beginning in #)
radeontool power on

This will take care of the problem, but needs integration work (so that it is
only used when the problem exists).

[Matthew Garrett (mjg59)]

This is not a major bug.

[Tim Hull (thully-arbornet)]

OK, sorry I marked it major - I guess since suspend is off by default in Hoary,
it is not major.
BTW, any progress on this yet? Is there any tests I could run that may help
resolve this problem. Also,
another thing that may relate into this is that currently, UltraNav and ethernet
lights aren't turned off by the suspend script - and that
consumes power.

[Tim Hull (thully-arbornet)]

Any way some type of fix for this could get into Hoary? Could the Radeon card
be forced into D2 sleep like in the kernel patch? This is known to solve the
problem on pretty much all machines with this issue (including mine).

[Matthew Garrett (mjg59)]

The patched radeontool does just that, but doesn't seem to work for everyone. We
need more testing feedback.

[Tim Hull (thully-arbornet)]

OK, so we're getting pretty late in the game for Hoary.
As a temporary solution, may it be viable to provide
1) A kernel identical to the normal Ubuntu kernel, except with radeonfb+enable
D2 patch applied
(this would be in universe, and clearly labeled "UNSUPPORTED" - specifically
only for the affected thinkpads).
2) Include radeontool on the standard install, but only run it on
startup/shutdown if a special option
is set in /etc/default/acpi-support (this wouldn't help me, but may help others)

I don't think I'd be able to help with this (partially because I'm sending my
laptop to IBM to have them fix some screen/keyboard issues) but if anyone has
some time this may be nice to have.

[Tim Hull (thully-arbornet)]

Also, has anyone approached IBM with this issue? I don't know who exactly to
contact, but it seems like this may be something that could be fixed in a BIOS
update.

[Marius Gedminas (mgedmin)]

My T42 (model 2373-FWG) also suffers from this problem (3600 mW during ACPI sleep).

I have tried radeontool-1.5-mjg, but without much luck: the laptop tends to lock
up hard with a black screen after a resume. I believe I had only two successful
resumes with radeontool, but one of them ended up with a crazy keyboard (and I
had to reboot), while another was on AC power, so I couldn't check battery usage.

Question: should I enable any of SAVE_VBE_STATE, POST_VIDEO, USE_DPMS,
DOUBLE_CONSOLE_SWITCH in /etc/default/acpt-support if I want to try radeontool?
 I had POST_VIDEO enabled and all others disabled. A regular suspend without
radeontool works fine with all these options disabled.

[Matt Zimmerman (mdz)]

Is this still an issue with the latest kernels and tools?

[Marius Gedminas (mgedmin)]

I solved this problem on my T42 (2373-FWG) by downloading the sources of
linux-image-2.6.12-4-686 (version 2.6.12-4.4) from Breezy and applying the
radeonfb patch from http://bugzilla.kernel.org/show_bug.cgi?id=3022. I also
added 'radeonfb' to /etc/modules. Suspend now does not drain the battery like
it used to.

The rest of my system is (mostly) Hoary. I had to explicitly list USB modules
in /etc/default/acpi-support (MODULES="usbhid uhci_hcd ehci_hcd") to get USB
back after suspend/resume -- that wasn't necessary with the Hoary kernel. I
also get a "could not initialize HAL" message on each login, but that's beside
the point.

I have not tried the latest kernel in breezy, but from what I've seen in its
changelog, there were no patches applied to fix the issue.
The version of radeontool in breezy does not support 'radeontool power off', so
I doubt that tools could have fixed the bug either.

[Anna Glasgall (aglasgall)]

Can this bug please get some love? It's really a pain in the neck to patch up
every time a new kernel comes out, and the fact that the patch at kernel
bugzilla bug#9720 (as referenced earlier in the thread) uses a whitelist to
decide whether or not to enable D2 means it won't break anything...

[Matt Zimmerman (mdz)]

The fix in #3022 is not ideal for us because it requires loading radeonfb (which
we don't do by default, as an explicit decision).

Matthew, would it be possible to work around this in acpi-support, or elsewhere?

[Ben Collins (ben-collins)]

Is there actually a way to put this device to sleep without loading radeonfb
module? If not, then we should look into using the patch from the kernel.org bug.

Matt, your input?

[Johannes Hessellund (osos)]

Please add the fix as it also solves the problem on my T42.
The fix uses a whitelist. So adding the patch will not harm any machine not on
the whitelist... = no risk

[Ben Collins (ben-collins)]

This bug has been flagged because it is old and possibly inactive. It may or may
not be fixed in the latest release (Breezy Badger 5.10). It is being marked as
"NEEDSINFO". In two weeks time, if the bug is not updated back to "NEW" and
validated against Breezy, it will be closed.

This is needed in order to help manage the current bug list for the kernel. We
would like to fix all bugs, but need users to test and help with debugging.

If this change was in error for this bug, please respond and make the
appropriate change (or email <email address hidden> if you cannot make the
change).

Thanks for your help.

[Johannes Hessellund (osos)]

Please. This is a real bug. AND a solution is at hand, use it!

I compiled myself a new kernel with the latest patch from
http://bugzilla.kernel.org/show_bug.cgi?id=3022 which solves this. It applies
flawlessly to the kernels i tried. ubuntus 2.6.12 up to vanilla 2.6.14.

I can't see any trouble for Ubuntu kernel to simply include this patch.

The patch uses a whitelist for hardware known to work, the rest can try it out
by adding radeon_force_sleep=1 as a module option.

[Johannes Hessellund (osos)]

Created an attachment (id=4954)
radeonfb_patch

Patch for the radeonfb, which reduces power usage while sleep for mobility
gpu's.

[Matthew Garrett (mjg59)]

This solution still requires the use of radeonfb, which is not generally
acceptable. I'm still looking into improving this, and have a couple of ideas.

[Johannes Hessellund (osos)]

(In reply to comment #29)
> This solution still requires the use of radeonfb, which is not generally
> acceptable. I'm still looking into improving this, and have a couple of ideas.

What is wrong in using the radeonfb?
As a preliminary solution?
This patch will be included anyway in kernel 2.6.15-2.6.16 ! Include it now,
make Thinkpad owners life more easy!

[Ben Collins (ben-collins)]

Patch is probably a suboptimal solution, but it's atleast something that can be
used. Including it for now. I'll back it out when something better comes along.

[Ben Collins (ben-collins)]

Fixed in 2.6.15-8.10

[Ben Collins (ben-collins)]

*** Bug 25567 has been marked as a duplicate of this bug. ***