Bug 3022 - S3: RADEON power consumption - Thinkpad T40/T41
Summary: S3: RADEON power consumption - Thinkpad T40/T41
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Console/Framebuffers (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Benjamin Herrenschmidt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-06 07:45 UTC by Volker Braun
Modified: 2008-07-17 15:55 UTC (History)
36 users (show)

See Also:
Kernel Version: 2.6.7
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
proposed patch (636 bytes, patch)
2004-07-19 00:30 UTC, Shaohua
Details | Diff
dmesg output (15.10 KB, text/plain)
2004-07-19 12:06 UTC, Volker Braun
Details
dmesg output on R40 (10.19 KB, text/plain)
2004-08-03 04:31 UTC, Nils Trebing
Details
output from acpidmp on R40 (180.10 KB, text/plain)
2004-08-03 04:33 UTC, Nils Trebing
Details
dmidecode output on R40 (11.70 KB, text/plain)
2004-08-03 04:35 UTC, Nils Trebing
Details
lspci output on R40 (10.12 KB, text/plain)
2004-08-03 04:36 UTC, Nils Trebing
Details
new proposed patch (730 bytes, patch)
2005-01-17 05:37 UTC, Michele Lamarca
Details | Diff
Whitelist specific models for D2 (2.47 KB, patch)
2005-01-24 13:17 UTC, Volker Braun
Details | Diff
Improved whitelist patch (2.71 KB, patch)
2005-01-24 14:46 UTC, Volker Braun
Details | Diff
Another whitelist patch with command line option for forcing (3.91 KB, patch)
2005-01-25 15:02 UTC, Antti Andreimann
Details | Diff
Extended whitelist patch (48.07 KB, patch)
2005-02-13 11:31 UTC, Volker Braun
Details | Diff
Updated whitelist patch (for 2.6.11-rc4) (9.42 KB, patch)
2005-02-20 12:09 UTC, Antti Andreimann
Details | Diff
Updated whitelist patch (for 2.6.12) (10.81 KB, patch)
2005-06-28 07:46 UTC, Antti Andreimann
Details | Diff
Added one more system to the whitelist (11.02 KB, patch)
2005-07-09 11:27 UTC, Brad Langhorst
Details | Diff
Updated whitelist. (14.61 KB, patch)
2005-07-12 11:28 UTC, Volker Braun
Details | Diff
Updated whitelist. (12.96 KB, patch)
2005-08-09 14:24 UTC, Wouter Cloetens
Details | Diff
Updated whitelist (2379D6U) and linenos (2.6.13.4) (13.13 KB, patch)
2005-11-01 19:45 UTC, Chris Frost
Details | Diff
yet another updated patch (15.66 KB, patch)
2005-11-29 23:25 UTC, Dave Jones
Details | Diff
Simplified whitelist patch (5.37 KB, patch)
2005-12-01 06:40 UTC, Thomas de Grenier de Latour
Details | Diff
radeonfb_d2_suspend-20051205.patch (6.91 KB, patch)
2005-12-05 05:14 UTC, Thomas de Grenier de Latour
Details | Diff
Updated patch for 2.6.16 (6.81 KB, patch)
2006-03-24 08:15 UTC, Ari Pollak
Details | Diff
Correct patch for 2.6.16 (5.63 KB, patch)
2006-03-31 05:26 UTC, Giorgio Lando
Details | Diff
radeonfb-2.6.16.patch (8.16 KB, patch)
2006-04-15 07:23 UTC, Giorgio Lando
Details | Diff
radeonfb-2.6.16.patch (8.16 KB, patch)
2006-04-17 02:50 UTC, Giorgio Lando
Details | Diff
radeonfb-2.6.16.patch (8.16 KB, patch)
2006-04-17 02:55 UTC, Giorgio Lando
Details | Diff
radeonfb-D2-2.6.16.patch (8.13 KB, patch)
2006-04-17 02:59 UTC, Giorgio Lando
Details | Diff
radeonfb-D2-2.6.16.patch (7.07 KB, patch)
2006-04-19 01:38 UTC, Giorgio Lando
Details | Diff
radeonfb-D2-2.6.16.patch (7.07 KB, patch)
2006-04-19 01:41 UTC, Giorgio Lando
Details | Diff
patch with a new whitelist (7.37 KB, patch)
2006-05-28 02:49 UTC, Giorgio Lando
Details | Diff
patch with a new whitelist (7.37 KB, patch)
2006-05-28 02:51 UTC, Giorgio Lando
Details | Diff
code improvement, same functionality. (9.13 KB, patch)
2006-06-29 13:14 UTC, Volker Braun
Details | Diff

Description Volker Braun 2004-07-06 07:45:51 UTC
Distribution: Fedora Core 2
Hardware Environment: IBM Thinkpad T41 2379DJU
Software Environment: Every 2.6 series kernel so far.
Problem Description: 

ACPI suspend to ram (S3) / resume works reliably (USB unloaded). However, when
suspended the computer draws too much power, about 5W. This translates to a
battery lifetime of about 10h. 

The thinkpad gets rather hot, especially if you put it into a (well-isolated) 
carrying case. This is why I set severity to high.

Using linux/APM or WinXP, there is no problem. Battery life in suspend to ram
state 1-2 weeks.

This bug seems to affect all T4* models.

Steps to reproduce:

[root@thinkpad root]# echo 3 > /proc/acpi/sleep
Jul  6 10:23:57 thinkpad kernel: Can't open /dev/console. Error value was -14.
Jul  6 10:23:57 thinkpad kernel:  hwsleep-0304 [302] acpi_enter_sleep_state:
Entering sleep state [S3]
Jul  6 10:23:57 thinkpad kernel: Warning: CPU frequency out of sync: cpufreq and
timingcore thinks of 600000, is 1600000 kHz.
Jul  6 10:23:57 thinkpad kernel: MCE: The hardware reports a non fatal,
correctable incident occurred on CPU 0.
Jul  6 10:23:57 thinkpad kernel: Bank 1: f200000000000135
Jul  6 10:23:58 thinkpad kernel: Warning: CPU frequency out of sync: cpufreq and
timing core thinks of 600000, is 1600000 kHz.
Jul  6 10:23:58 thinkpad kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100
Mbps Full Duplex
Comment 1 Nils Trebing 2004-07-09 03:05:34 UTC
The same problem also exists on R40 models. FWIW, the green indicator light on
the CD drive stays on while suspended.
Comment 2 Vernon Mauery 2004-07-09 11:26:25 UTC
I don't think the CD-ROM LED is a problem - with WinXP suspend, the LED is on
too, but the machine cools off (even if it is stuffed in a bag) and does not
drain the battery at the same rate it does under Linux.  But it is good to know
which models this affects.
Comment 3 Steve Harris 2004-07-14 09:41:02 UTC
On my 2373GKG (UK) T41p, std life battery, running FC2 (2.6.6-1.435) the
situation is reversed, ACPI suspend to ram lasts for a few days (and doesn't get
hot, even in a sealed case). Unsupending is not 100% relaible, with USB module
unloaded, but its close.

With APM the batttery life was only a few hours. I dont remeber if it got
particularly hot.
Comment 4 Alex Cozzi 2004-07-14 23:51:36 UTC
Same problem on debian unstable with debian kernel 2.6.7-1-686 on a Thinkpad T40 (model 
2373-MU3). Updated to the latest BIOS does not fix it. 
 
Comment 5 Shaohua 2004-07-19 00:30:22 UTC
Created attachment 3397 [details]
proposed patch

Does this patch help a little? Thanks, shaohua
Comment 6 Volker Braun 2004-07-19 12:04:53 UTC
I tried the proposed patch id=3397, and there is no noticeable difference in
power usage. It still draws around 5W during S3.

From various sources I gathered the following list of working/not working
T-series thinkpads (apart from the first one I cannot verify them myself though):

Affected by bug:
T41  2379-DJU
T40  2373-MU3
T40  2373-92U
T40p 2373-G1U 

Not affected:
T41p 2373-GKG

The unaffected T41p sets itself apart from the others by its ATI Mobility FIREGL
T2 graphics and the 1.7GHz Pentium-M. My guess is that it is either a BIOS fluke
or one of these two factors.

For reference, on my T41 (2379-DJU, newest bios 3.06f) I get the following AML
errors, but I do not think that they cause the problem:

------------- dmesg snip on ------------
Executing all Device _STA and_INI
methods:........................................................ exfldio-0143
[22] ex_setup_region       : Field [PWKI] access width (4 bytes) too large for
region [U7CS] (length 2)
 exfldio-0155 [22] ex_setup_region       : Field [PWKI] Base+Offset+Width 0+0+4
is beyond end of region [U7CS] (length 2)
 exfldio-0179: *** Warning: The ACPI AML in your computer contains errors,
please nag the manufacturer to correct it.
 exfldio-0182: *** Warning: Allowing relaxed access to fields; turn on
CONFIG_ACPI_DEBUG for details.
 exfldio-0143 [22] ex_setup_region       : Field [PWKI] access width (4 bytes)
too large for region [U7CS] (length 2)
 exfldio-0155 [22] ex_setup_region       : Field [PWKI] Base+Offset+Width 0+0+4
is beyond end of region [U7CS] (length 2)
 exfldio-0143 [22] ex_setup_region       : Field [PWUC] access width (4 bytes)
too large for region [U7CS] (length 2)
 exfldio-0155 [22] ex_setup_region       : Field [PWUC] Base+Offset+Width 0+0+4
is beyond end of region [U7CS] (length 2)
 exfldio-0143 [22] ex_setup_region       : Field [PWUC] access width (4 bytes)
too large for region [U7CS] (length 2)
 exfldio-0155 [22] ex_setup_region       : Field [PWUC] Base+Offset+Width 0+0+4
is beyond end of region [U7CS] (length 2)
....
60 Devices found containing: 60 _STA, 9 _INI methods
------------- dmesg snip off ------------
Comment 7 Volker Braun 2004-07-19 12:06:40 UTC
Created attachment 3401 [details]
dmesg output
Comment 8 Vernon Mauery 2004-07-20 12:40:41 UTC
There was discussion about this on the LKML that went along the lines that in
S3, the screen could still be seen (at least by some) and I was wondering if
this might be related to why so much power is being drawn.  Driving the LCD
itself (not the backlight) probably doesn't take TOO much power, but having it
turned off might be one step closer to the 2 week suspend.

I found that if I use vga=normal or vga=791 (VESA framebuffer) I can see a ghost
image of what is really on the screen while in S3.  If I compile the radeonfb
into my kernel, I cannot see any image in S3.

BTW, this is all on a 2.6.7 kernel with the acpi-20040715 patch applied.
Comment 9 Robert Fries 2004-07-24 21:43:16 UTC
I am seeing the excessive heat and battery consumption with both apm and acpi 
using linux-2.6.7 (under Fedora-core2) on a thinkpad a30p 2653-66u.   I have 
used apm under a wide range of kernels (I have had this laptop for 3 years) 
and this is the first kernel on which I have seen this problem. 
Comment 10 Jürg Billeter 2004-08-01 05:15:24 UTC
I have exactly the same problem with a Thinkpad T40p 2373-G1G with the most
current BIOS and EC running 2.6.8-rc2-mm1 with ACPI and radeonfb activated. With
Linux 2.4 APM, 2.6 APM and WinXP ACPI there is absolutely no heat / power drain
problem. The hot spot seems to be near the CPU (Pentium M 1.6) but I don't know
whether it's the cpu itself or something nearby draining power (chipset, gpu?).

What additional information is needed to narrow the problem down? I'd be happy
providing more information or testing patches. I can provide DSDT if an
error/particularity therin could be the origin of the problem.
Comment 11 Nils Trebing 2004-08-03 04:29:36 UTC
Now I've tested on my R40 2722-5MG with 2.6.8-rc2 and the following patches:  
the proposed patch from this bug, the patch from bug #1415, the dsdt-initrd  
patch v0.4-2.6.7 from http://gaugusch.at/kernel.shtml (because there were 3  
errors in the original DSDT which where trivial to fix following the advice at  
http://www.cpqlinux.com/acpi-howto.html) and the patch from  
http://bellet.info/laptop/disable-lapic-in-acpi-power-off-2.6.7.diff . The  
computer still draws around 4W when suspended to RAM. I get the following  
output when echoing 3 to /proc/acpi/sleep:  
  
PM: Preparing system for suspend  
Stopping tasks: ========|  
radeonfb: suspending to state: 2...  
PM: Entering state.  
Back to C!  
PM: Finishing up.  
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 9 (level, low) -> IRQ 9  
ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 6 (level, low) -> IRQ 6  
PCI: Setting latency timer of device 0000:00:1f.5 to 64  
ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 6 (level, low) -> IRQ 6  
PCI: Setting latency timer of device 0000:00:1f.6 to 64  
radeonfb: resumed !  
Restarting tasks... done  
  
BTW, when I suspend to RAM using APM, battery life is much better, and  
radeonfb is "suspending to state: 3" according to dmesg.  
  
Should I test with the latest ACPI patch and/or without the patch from this  
bug?  
Comment 12 Nils Trebing 2004-08-03 04:31:38 UTC
Created attachment 3462 [details]
dmesg output on R40
Comment 13 Nils Trebing 2004-08-03 04:33:37 UTC
Created attachment 3463 [details]
output from acpidmp on R40
Comment 14 Nils Trebing 2004-08-03 04:35:18 UTC
Created attachment 3464 [details]
dmidecode output on R40
Comment 15 Nils Trebing 2004-08-03 04:36:03 UTC
Created attachment 3465 [details]
lspci output on R40
Comment 16 Dimitris 2004-08-09 04:28:47 UTC
I think i'm having the same problem. I've got a TP A31p which doesn't last long
in suspend mode. In addition to that, my USB dies after i resume.

I've decoded/recompiled my DSDT and the compiler reports no errors (though it
reports 2043 optimizations).

I'm also using Fedora Core 2 and i've opened two bugs in redhat's bugzilla, here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129413
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129405
Comment 17 Dimitris 2004-08-10 10:30:25 UTC
I can confirm that my A31p uses too much power (dies overnight) and one of the
reasons is that the LCD backlight is never shutdown!

I can clearly see that after a suspend (S3) the backlight is fully operational
and it can be demonstrated in a dark room or by just looking at the edges.
Comment 18 Volker Braun 2004-08-28 14:52:58 UTC
First of all, my LCD backlight is definitely off during S3. Everybody with
backlight on knows the origin of the power drain, and suffers from a different bug.

Some tests done to try to isolate the problem during S3 sleep:

1) Boot with acpi_os_name="Microsoft Windows NT" or acpi_os_name="Microsoft
WindowsME: Millennium Edition". Those tests appear in IBM's dsdt. 

2) Physically remove ultrabay device.

3) Add "if (state>0) state=3;" at the beginning of suspend_device(),
linux/drivers/base/power/suspend.c in kernel 2.6.8.1. This forces every PCI
device to D3hot sleep. Suspend/Resume (without ehci_hcd) still works for me.

4) Same with "if (state>0) state=4;", forces D3cold. Suspend/Resume works
partially, ultrabay does not come back.

None of these change the power consumption during acpi S3, which remains in
every case at about 5W. 
Comment 19 Volker Braun 2004-10-19 13:32:45 UTC
Here is the only difference I noticed between Windows XP and Linux 2.6.8.1 ACPI
S3 sleep: The ethernet activity leds are off in WinXP and on in Linux sleep. So
to be precise:

WinXP sleep:
green link status led: off
amber activity led: off

Linux sleep:
green link status led: active (always on)
amber activity led: active (blinks as packets arrive).

Could it be that the ethernet generates interrupts which keep the cpu from deep
sleep? The power drain issue also happens without any ethernet cable plugged in.

Does everybody with lcd off during suspend yet mysterious power drain see the
same behaviour of the ethernet leds?
Comment 20 Joachim Klein 2004-10-24 08:37:44 UTC
Hardware: Thinkpad T42 2373-5WG
Kernel: Linux 2.6.7

I can confirm that the ethernet LEDs stay on in S3 and react to traffic. During
the switch to S3, the link status LED (green) is off for about a second before
switching back on. The LCD backlight is off.

With WinXP suspend, the ethernet LEDS are off and there is no power drain.
Comment 21 Joachim Klein 2004-10-26 10:26:48 UTC
It seems that the ethernet LEDs are on if wake-on-lan is activated. If you
deactivate it with 'ethtool -s eth0 wol d', the LEDs are off in S3.
Unfortunately, this doesn't seem to change the power consumption...
Comment 22 Adrian Yee 2004-11-25 13:17:14 UTC
I have a T42 (2378FVU) that seems to not have any power drain problems with S3.
 I did a `cat /proc/acpi/battery/BAT0/state; echo mem > /sys/power/state; cat
/proc/acpi/battery/BAT0/state` and about 11 hours later, the battery had used
about 5W - that's around 4.5 days of battery life in S3 (6.5 with extended battery).

This was done on a stock 2.6.9 kernel.  Ultrabay light was on, ethernet was
unplugged, but it is on if a cable is plugged in (WOL is off in bios).
Comment 23 Ari Pollak 2004-12-02 09:28:37 UTC
This is the last remaining bug keeping me from using ACPI on my Thinkpad T41
(other than the weird ALSA intel8x0 suspend problem in 2.6.10-*, but that can be
worked around)
Comment 24 Joel Ebel 2004-12-02 09:33:53 UTC
I have figured out the cause for a similar power drain in windows.  I have only
tested Windows.  I don't use ACPI in Linux, and APM sleep has always worked
fine.  I don't know if this will help those who are experiencing a similar
problem in Linux or not, but here's what I found out.  Starting with BIOS 3.06f
for my T40, a feature was added to prevent the computer from waking up from
sleep on a timer.  This was done to prevent the hard drive from operating while
the computer wasn't stationary.  However, apparently, when the computer tries to
wake up from standby to go into hibernation, it begins to use more power, and it
never shuts off.  There are two solutions I found to this problem.

1.  Make sure the OS isn't set to wake up from standby in order to go into
hibernation.
2.  Enable the option in the BIOS to allow the computer to wake up from standby
with a timer.

Either of these seems to work fine for me in Windows.  Hopefully they will help
in the search for the solution for Linux.

Joel Ebel 
Comment 25 Ed Hill 2004-12-29 12:38:33 UTC
ThinkPad A22p (2629-Y1U)
Kernel 2.6.9-1.681_FC3  (latest FC3 update)

I get exactly the same problem.  The ACPI S3 state works but the laptop becomes
rather hot and the battery usage is many times higher than APM suspend-to-RAM.
Comment 26 Jan-Hendrik Benter 2005-01-07 01:15:05 UTC
I have the same problem with vanilla 2.6.10 and T40P (2373-G3G), during S3 it 
still uses around 2 watts and stays _warm_. 
 
Regards, 
 
Jan-Hendrik 
Comment 27 Tim Mann 2005-01-15 15:55:35 UTC
There is a page about this bug, with a test script and a summary of affected and
unaffected models, at
http://www.thinkwiki.org/Problem_with_high_power_drain_in_ACPI_sleep

There's a discussion at
http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-January/022703.html

No one has a solution.
Comment 28 Jürg Billeter 2005-01-15 17:58:44 UTC
I've done some more tests today and seem to come closer to a possible solution.
On my system (Thinkpad T40p 2373-G1G) the problem is definitively caused by the
radeon chip (Mobility FireGL 9000). Compiling Linux 2.6.10 with radeonfb with
the following tiny change reduced the power drain to about 0.6 W.

The only change I've done was removing the CONFIG_PPC_PMAC condition in
drivers/video/aty/radeon_pm.c, i.e. suspend to D2 even though this is not a
PowerMac.

I'll contact Ben. Herrenschmidt, the author of the new radeonfb.
Comment 29 Benjamin Herrenschmidt 2005-01-16 19:22:46 UTC
Ok, it isn't that simple. The D2 code in there has really only been tested on
PowerMac laptops, more specifically, it does reprogram the SDRAM's with timings
that are only known to work with whatever Apple use in their laptops.

Also, on x86, I don't think D2 is the right mode to use, the card is supposed to
be put into D3, but then, I don't have the proper procedure for that (though
it's possible that "just doing  it" works, and then, you may have a hard time
getting it back if your BIOS doesn't do it for you).

I don't know, really, what should be done on x86 machines. I know some ppl at
ATI are working on it, though, but I don't know anything about the status there.

Comment 30 Jan-Hendrik Benter 2005-01-17 04:02:34 UTC
Hmmm ... 
 
I have now seen two people reporting that it greatfully improved the issue 
(e.g. 2.7W => 0.8W). So it seems to be related with 
drivers/video/aty/radeon_pm.c. I don't want to damage my hardware, so I don't 
want to play with it. Could anybody who has successfully tried it post a diff. 
Also maybe Benjamin Herrenschmidt could give some more comments on what these 
changes would do ... 
 
Regards, 
 
Jan-Hendrik 
Comment 31 Michele Lamarca 2005-01-17 05:37:58 UTC
Created attachment 4426 [details]
new proposed patch
Comment 32 Vernon Mauery 2005-01-17 10:13:28 UTC
I tested the new proposed patch with a 2.6.10 kernel on my T40 which has a
Radeon Mobility M7 LW [Radeon Mobility 7500] and it does not come out of S3.
Comment 33 Henrik Brix Andersen 2005-01-17 10:25:25 UTC
You might want to try 2.6.11-rc1 - that one fixed the black-screen-on-resume for
me (IBM ThinkPad X31).
Comment 34 Michele Lamarca 2005-01-17 11:22:00 UTC
Ops, I forgot some details:
ThinkPad T40 2373-22G (radeon 7500)
Kernel 2.6.10-mm3
-- alsa resume patch found at http://lkml.org/lkml/2005/1/11/120 (Vernon, you
must apply this one too)
-- new proposed patch (suggested by J
Comment 35 Volker Braun 2005-01-17 12:27:29 UTC
Does not work for me (T41 2379DJU, Radeon Mobility 9000). Tried with 2.6.9
kernel where S3 sleep is reliable. With the proposed patch machine does no
longer wake up. 

It looks like it does not even enter sleep: After I suspend, the backlight turns
off but there is still activity on the screen. Especially, there is a ~5mm wide
band in the middle of the screen flashing at about 2Hz. 
Comment 36 Vernon Mauery 2005-01-17 15:54:41 UTC
I tried the new patch again with the alsa patch.  I also tried it against
2.6.11-rc1.  Both times, it still failed to come back to life.  I does try to
start back up -- the hard drive spins up and the cpu fan starts back up, but it
doesn't ever get far enough to print anything out on the console.

I tried using a port replicator to get access to my serial port set
console=ttyS0 to log the kernel messages.  It printed messages until the machine
entered S3 and nothing when it tried to start back up.  I upped the acpi debug
level to 0xa800031f, in hopes that it might spit something out useful.  It
dumped tons of stuff before sleeping, and then again, nothing after.

So, where ever it crashes, it seems to be before it gets the consoles going again.
Comment 37 Peter Fr 2005-01-18 05:57:38 UTC
Tested the patch on an IBM Thinkpad R40 2722-B3G
Could not even reach S3 with a 2.6.9 kernel, 
but:
with a recent kernel 2.6.11-rc1 this patch ist working and I reduced the power
to 0.8W/h in S3 Mode, the s3 test script from the thinkpadwiki reported the
following:
before: 49540 mWh
after: 49160 mWh
diff: -380 mWh
seconds: 1531 sec
result: -893 mW

Congratulations, your model seems NOT to be affected.
Comment 38 Nils Trebing 2005-01-19 12:43:42 UTC
The patch also works for me. Power consumptions has gone down to 0.8 mW
Comment 39 Thomas de Grenier de Latour 2005-01-19 13:12:46 UTC
Unfortunatly, this patch won't work for me. The thinkpad doesn't resume, whereas
it does fine without the patch.  
T40 2373-75G, Radeon Mobility 7500.
Comment 40 Nils Trebing 2005-01-19 13:24:08 UTC
Thomas, have you tried with a recent kernel version? First, I tried with 2.6.8
and couldn't resume either, but with 2.6.11-rc1, it works fine.
Bonne chance!
Comment 41 Thomas de Grenier de Latour 2005-01-19 13:36:29 UTC
Merci ;)

Actually, i've tried with 2.6.10-as2, because i thought that since it was
resuming fine without the patch, switching to 2.6.11 wouldn't change much the
result. But i will try, just to be sure.
Comment 42 Thomas de Grenier de Latour 2005-01-19 14:57:09 UTC
Nils, thanks again, you were perfectly right. 2.6.11-rc1+patch resumes fine,
here are my results:

before: 28580 mWh
after: 28400 mWh
diff: -180 mWh
seconds: 1405 sec
result: -461 mW


Sure that test was a bit short, so it may not be 100% accurate, but that's
enough to show that it works very fine. For comparaison, without the patch and
on 2.6.10, i got this yesterday:

before: 28120 mWh
after: 27290 mWh
diff: -830 mWh
seconds: 1010 sec
result: -2958 mW
Comment 43 Tomas Lund 2005-01-22 05:58:16 UTC
I have a Thinkpad T41 2373-4FG with Radeon Mobility 7500.

Trying 2.6.11-rc2 with the patch applied to radeon_pm.c, it does not come out of
s3 sleep.

Suspending, closing and opening the lid I can hear it start the resume (noice
from CD-ROM) but screen remains blank and no beeps.

Output from dmesg, lspci and .config available at http://tlund.pp.se/thinkpad/
Comment 44 Matthew Garrett 2005-01-24 08:31:42 UTC
Looking at the radeonfb source, it seems that some registers need to be set in
order to get the Radeon to usefully power itself down. I've tested this briefly
- naively setting the hardware to D3 doesn't result in significant power saving.

It's not clear to me that the generic PM code should be expected to know that
certain chips need extra stuff doing to them in order to save power. Unless
there's code in the DSDT that does this and isn't being called, it sounds more
like a radeonfb issue than anything else.
Comment 45 Volker Braun 2005-01-24 13:17:40 UTC
Created attachment 4454 [details]
Whitelist specific models for D2

I agree that this turned out to be a radeonfb issue. However, it is only
triggered by ACPI whereas APM seems to do the right thing.

After some more testing I solved my problems. These were 1) hang during resume
and 2) power drain. On top of kernel 2.6.11-rc2 I added the following patches
from -mm1:

radeonfb-build-fix.patch
radeonfb-massive-update-of-pm-code.patch
radeonfb-set-accelerator-id.patch
acpi-sleep-while-atomic-during-s3-resume-from-ram.patch
add-try_acquire_console_sem.patch

(Note: they can all be found in
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/)


With these patches I can successfully suspend and resume, but suffer from the
power drain issue. On top of these patches I added radeonfb-thinkpad-pm-2.patch
from Antti Andreimann <Antti.Andreimann@mail.ee>, which selectively whitelists
special models. Now the laptop uses about 700mW while in S3 suspend, which is
way closer to the expected usage.

The radeonfb-thinkpad-pm-2.patch comments out the following call

    OUTREG(BUS_CNTL1,
	   (INREG(BUS_CNTL1) & ~BUS_CNTL1__MOBILE_PLATFORM_SEL_MASK)	       
	       
	   | (2<<BUS_CNTL1__MOBILE_PLATFORM_SEL__SHIFT));   // 440BX

Does anyone know what this does? Suspend/resume works for me without this call,
but if it is included then my machine hangs during resume. More specifically,
it hangs if and only if X was started any time before the suspend attempt. For
example, start X -> end X -> suspend -> resume -> hang.
Comment 46 Matthew Garrett 2005-01-24 14:40:16 UTC
In APM, the BIOS is responsible for shutting down the card. In ACPI, it's the
OS. The BIOS presumably knows which bits to set in the card, and the Windows
drivers probably know the same.
Comment 47 Volker Braun 2005-01-24 14:46:11 UTC
Created attachment 4455 [details]
Improved whitelist patch

I have been told that the section does something fiddly with the northbridge
and is the right thing for PMACs. Therefore, we should keep it but disable for
x86. The new patch does just that.
Comment 48 Antti Andreimann 2005-01-24 15:41:11 UTC
Ok, to summarize the ACPI S3 power drain seems to have at least 4 apparent
components (compared to APM suspend): 
1. Video chip (radeon) is not turned off - most significant component
2. Ethernet adapter leds remain on
3. Ultrabay light (next to CDROM drive) remains on
4. USB power (for external devices) remains on

The first can be hopefully cured by posted patches.
The second is not a kernel issue and can be cured by turning off wake-on-lan:
ethtool -s eth0 wol d
The third is not a kernel issue and can be cured by ejecting ultrabay before
suspend: echo eject > /proc/acpi/ibm/bay. See http://ibm-acpi.sourceforge.net/
for some acpi scripts to get Your CD back afterwards ;)
The fourth is probably because usb hub driver does not turn off power on it's
ports but this is plain speculation, I havent checked the code myself.

As said, the most significant component is Radeon chip so others can be pretty
much ignored for now ;)
Comment 49 Antti Andreimann 2005-01-24 16:39:14 UTC
Here are some instructions how to get the patches to work.
First determine Your thinkpad model number. This can be done in two ways:
1. Look under the laptop, it is written on a sticker.
2. run dmidecode | grep 'Product Name:'

Then add Your model to the top of drivers/video/aty/radeon_pm.c (if it's not
there already).
When You suspend/resume You should see the following lines in dmesg:
radeonfb (0000:01:00.0): suspending to state: 3...
radeonfb: switching to D2 state...
radeonfb (0000:01:00.0): resuming from state: 3...
radeonfb: switching to D0 state...

If You only get:
radeonfb (0000:01:00.0): suspending to state: 3...
radeonfb (0000:01:00.0): resuming from state: 3...

You haven't got the model numbers right (D2 was not enabled).

Another small request:
If some1 tries the patches successfully, please post the results here: at least
model number and kernel version.
Comment 50 Peter Fr 2005-01-25 04:50:07 UTC
Here the logs from dmesg:
radeonfb (0000:01:00.0): suspending to state: 3...
radeonfb: switching to D2 state...
radeonfb (0000:01:00.0): resuming from state: 3...
radeonfb: switching to D0 state...
radeonfb (0000:01:00.0): suspending to state: 3...
radeonfb: switching to D2 state...
radeonfb (0000:01:00.0): resuming from state: 3...
radeonfb: switching to D0 state...

seems to work so far.

patches:
2.6.10 vanilla
2.6.11-rc2

I extracted the following patches from the 2.6.11-rc2-mm1 file (the broken out
files, don`t apply cleanly)
ati_ids.h
radeon_base.c
radeonfb.h
radeon_monitor.c
radeon_pm.c
radeon.h

I took from the mm1 broken-out directory:
acpi-sleep-while-atomic-during-s3-resume-from-ram.patch
add-try_acquire_console_sem.patch
radeonfb-build-fix.patch

At last, I modified the "Improved whitelist patch" to fit for my model

model: IBM Thinkpad R40 2722-B3G

I can post this patchset, i think it`s more easy to use
Comment 51 Volker Braun 2005-01-25 08:42:17 UTC
Here is an attempt to make it easier to test. I'll send the same message to the
linux.hardware.thinkpad mailinglist. Hopefully we will get some impression how
well this patch works.

---------------------------------------------------------------
Please help us test the radeon powermanagement patch. This is supposed
to solve the "S3: high power consumption" bug detailed in
http://bugzilla.kernel.org/show_bug.cgi?id=3022

If you do not want to hunt down the individual patches from the
bugzilla entry, then there are two ways to test. First, if you happen
to use Fedora Core 3 on a thinkpad T4x series, then there are
precompiled kernel rpms. The following kernel has all the necessary
patches (and software-suspend-2) applied

http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/kernel-DANGEROUS-T4x-2.6.11-8.i386.rpm

Install it, and run (as root) /usr/bin/thinkpad-T4x-suspend. This
script will suspend your computer and log the battery drain to
/var/log/battery.log. The "DANGEROUS" refers to the fact that this
kernel suspends the radeon chip to D2 sleep, and we are not sure
whether this works with all revisions of the hardware. 

If your computer hangs during resume, please try 

http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/kernel-T4x-2.6.11-8.i386.rpm

This is almost the same kernel, but sends the radeon to D2 sleep only
on models where it is known to work. Now, you should definitely be
able to suspend/resume, but you may suffer of the battery drain bug
during sleep.

If you do not use Fedora Core 3 or have different hardware, you can
also compile a kernel yourself. First, get the vanilla 2.6.10 kernel
sources. Then apply

http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/i386/patch-2.6.11-rc2-radeonfb-D2.patch.bz2

This patch unconditionally enables D2 sleep for the radeon chip. If
you have a T4x thinkpad, you can use my kernel config at

http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/config

Then compile, install, and test. 

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.
---------------------------------------------------------------
Comment 52 Vernon Mauery 2005-01-25 11:43:11 UTC
I followed the instructions, patched a 2.6.11-rc2 kernel with the mm1 patches
(some were done by hand because the patches didn't apply cleanly) and tested. 
My usage went from 4.3 W to 1.1 W.  While this is not perfect, I think it is a
big enough change to add it to the whitelist and keep using the patch.  My
machine type is 2373-mu4.
Comment 53 Paul Ionescu 2005-01-25 14:04:23 UTC
I just tried on FC2 this kernel:
http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/kernel-DANGEROUS-T4x-2.6.11-8.i386.rpm
It works on my T41 model 2373-TG5.
Power usage is 1.24 W/27 minutes now and before was 3.4 W/25 minutes.

It is not yet as low as in it should be, but it is an improvement.
Comment 54 Antti Andreimann 2005-01-25 15:02:08 UTC
Created attachment 4467 [details]
Another whitelist patch with command line option for forcing

Functionally equivalent to the previous whitelist patch, added command line and
module option force_sleep to force D2 on non-whitelisted hardware (for easier
testing). This is how You do it:
1. pass video=radeonfb:force_sleep to kernel command line
2. or do modprobe radeonfb force_sleep=1 when compiled as a module
You should see the following message in dmesg:
radeonfb: forcefully enabling sleep mode
NB! We still need model numbers for the whitelist
Comment 55 Michele Lamarca 2005-01-26 06:16:48 UTC
Successfully applied patch "Improved whitelist patch" to 2.6.11-rc2-mm1

It works on my ThinkPad T40 model 2373-22G
Comment 56 Jakob Schi 2005-01-27 03:06:23 UTC
I have a ThinkPad T30, and I see the large power drain (4630 mWh in 2h36min
corresponding to 1.78 W or 5% of the battery per hour).  While it is not as bad
as some reports, it is still more than the 1.1% per hour in Windows.

I have NOT enabled framebuffer support in my kernel.  Is the patch in comment
#51 still relevant to me?

demokrit linux # zcat /proc/config.gz | grep ATI
# CONFIG_MATH_EMULATION is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_AGP_ATI is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_JFS_STATISTICS is not set
demokrit linux # zcat /proc/config.gz | grep RADEON
CONFIG_DRM_RADEON=y
demokrit linux # zcat /proc/config.gz | grep FB
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_FB is not set
Comment 57 Antti Andreimann 2005-01-27 06:03:34 UTC
You have to enable radeonfb and apply the patch to check out if it helps.
Comment 58 Jakob Schi 2005-01-28 05:56:55 UTC
I tried to use the patch "Another whitelist patch with command line option for
forcing", but when I compile the kernel with framebuffer support X fails (black
screen, mouse cursor visible and moving, keyboard completely dead). The
framebuffer works fine during boot, but once X comes up the machine is useless.
 It is probably not the patch, but framebuffer support for this machine. 

Thinkpad T30 type 2366.

PS.  I usually always use X and don't use a framebuffer.  Is there any
advantage/disadvantage to use the framebuffer in that case?

Comment 59 Volker Braun 2005-01-28 07:51:30 UTC
The extra power drain is apparently caused by the radeon chipset, which does not
go to powersaving mode if one just enters acpi S3. It expects some driver to do
that in software. Under Linux, that would be the frame buffer (or vga console).
Obviously, only the radeon frame buffer can possibly come with detailed
knowledege of the radeon chipset.

To summarize: Your only hope to solve the S3 power drain bug is radeonfb.
Comment 60 Alaw Guo 2005-01-29 13:08:30 UTC
Using Volker's kernel rpms the patch worked for me (2379-DJU) - at least it
reduced my power consumption.  However, I have problems with 2.6.11-rc2 that
makes my wireless card go crazy (Atheros Communications, Inc. AR5212 802.11abg
NIC (rev 01)) the problems are fixed in the latest bk patches, but I can't get
the kernel to compile with the radeon patches.
Comment 61 Antti Andreimann 2005-01-29 13:40:55 UTC
to: Jakob

Do you have Option "DynamicClocks" "True" in Your X config?
If not - add it, if yes - try to turn it off for a moment.

I find that my machine hangs sometimes during the boot (display initialization)
and dynamic clock has something to do with it.
It used to happen with X too.
Comment 62 Frank Schmitt 2005-01-29 15:29:16 UTC
Tried on my R40 2722-3GG, power consumption goes down to 1260 mW/h so this model
should be added to the whitelist.
Comment 63 Jakob Schi 2005-02-02 05:12:13 UTC
I tried the "Another whitelist patch with command line option for forcing" on my
IBM thinkpad T30 2366 failure with a Radeon Mobility 7500

It was not a success:

Using the internal display, it hangs when waking up from suspend.
Using it in a port replicator with a flat screen connected with a digital cable,
the machine hangs with a black screen and a dead keyboard when X starts.

None of these problems are seen with the plain 2.6.11-rc2 kernel with radeonfb
enabled.
Comment 64 Volker Braun 2005-02-13 11:31:57 UTC
Created attachment 4543 [details]
Extended whitelist patch

I added all models for which I got success reports to the whitelist. This patch
applies on top of kernel 2.6.11-rc3 + swsusp2 2.1.6 (the latter includes the
radeon patches).
Comment 65 Henrik Brix Andersen 2005-02-13 14:19:22 UTC
You can add the IBM ThinkPad X31 2672-XXH to the whitelist. I've just tested
with 2.6.11-rc3 + swsusp-2.1.6.

This patch doesn't fix the LCD backlight on during S3 issue, though.
Comment 66 Matthew Saltzman 2005-02-19 17:12:38 UTC
Please add model 2373-7JU (Radeon 7500M) to the whitelist.  Power consumtion
with kernel-DANGEROUS-T4x-2.6.11-8.i386.rpm (recompiled for i686) was 670 mW
over 31780 sec, and it resumes just fine.

BTW, it would be nice if that kernel didn't depend on ipw2200-firmware.  Many of
us don't have that device and don't need the firmware.

Also, I have vga=791 as a kernel option.  With this kernel, I see some screens
in that mode and some screens in a different mode with larger, uglier fonts.  Do
I want to use the Radeon FB on boot?  What options do I need and how can I
control the font?

Thanks for your work on this problem.  This looks like it makes ACPI usable for
many of us.
Comment 67 Antti Andreimann 2005-02-20 12:09:41 UTC
Created attachment 4576 [details]
Updated whitelist patch (for 2.6.11-rc4)

Updated patch to apply cleanly on 2.6.11-rc4.
Includes all whitelist entries that were present in Volkers last patch + few
new ones picked up from the comments on this page.
Comment 68 ChazeFroy 2005-02-21 07:36:41 UTC
Attachment 4576 [details] by Antti Andreimann for vanilla 2.6.11-rc4 works flawlessly on
my T30 2366-QU5.  LCD properly shuts off when going into S3 suspend, and it
resumes fine.  You can whitelist my system.
Comment 69 Jakob Schi 2005-02-23 04:42:26 UTC
Attachment 4576 [details] "Updated whitelist patch (for 2.6.11-rc4)" works on my T30
2366-96G.  It wakes up from suspend to ram, and only uses 790 mW while
suspended, versus 4.6 W without the patch.

There are a few quirks with the framebuffer on that system (e.g. bug 4147), but
they are unrelated to the patch.
Comment 70 Matthew Garrett 2005-02-28 17:16:42 UTC
I'm most of the way into a solution that would do this from userspace. I'm just
waiting to hear back from a test run, and then I'll post the code. This would
let suspend/resume work properly for people using vgacon.
Comment 71 Matthew Garrett 2005-03-01 16:13:33 UTC
Ok. The code at http://www.srcf.ucam.org/~mjg59/radeon/ seems to work. You'll
also need vbetool from http://www.srcf.ucam.org/~mjg59/vbetool/ (it's in Debian
unstable) and a suspend script that does something like the following:

FGCONSOLE=`fgconsole`
chvt 12
radeontool power off
echo -n 3 >/proc/acpi/sleep
radeontool power on
vbetool post
chvt $FGCONSOLE

This ought to solve the power consumption issue on vgacon. I wouldn't recommend
trying it if you're using radeonfb. You probably also want to lose
acpi_sleep=s3_bios if you're using it.
Comment 72 Tim Hull 2005-03-03 15:45:17 UTC
I tried Volker Braun's Fedora "DANGEROUS" kernel package on my ThinkPad,
and it seemed to rectify this problem for me.  However, as my laptop is not in the
whitelist, his other kernel did not rectify the problem.  Could my laptop be
added to the whitelist?  It is a ThinkPad T42 model 2374-6VU.  Also, will this
patch work on 2.6.11 kernel.org source?  I hope to see something for this in 2.6.12.
Comment 73 Tim Mann 2005-03-06 00:38:07 UTC
The user space solution looked attractive to me, so I've just tried Matthew
Garrett's modified radeontool on my 2379-DJU (Radeon Mobility 9000 M9). 
Unfortunately, the "power off" command doesn't appear to do anything on this
system.  As a simple test, I tried the script given, but with just a 10-second
delay in place of actually going into ACPI sleep.  I still had a blinking cursor
on the screen (and the backlight remained on) during the time that the radeon
chip was supposed to be powered off.
Comment 74 Dimitris 2005-03-07 02:28:45 UTC
I'm using an IBM ThinkPad A31p with Fedora Core 3.

Unfortunately my machine seems affected by high power drain. The script shows:

before: 35340 mWh
after: 32390 mWh
diff: -2950 mWh
seconds: 2597 sec
result: -4089 mW
Your model seems to be affected.

I am not using radeonfb so i can't use any of the patches, plus i dont have
the time to play with custom kernels at the moment. Hopefuly something will
come up soon :]
Comment 75 Chris Chiappa 2005-03-12 15:03:36 UTC
Just another confirmation that the T42 2378-FVU doesn't seem to have the drain
problem.  The script provided doesn't let me resume properly (with or without
radeonfb - the scripts that use vbetool to save and restore work fine tho), but
the log file does get written out and indicates that I used about .6W/hr.
Comment 76 Didrik Pinte 2005-03-15 11:27:32 UTC
Hi,

R50 (1829-7RG) seems also affected by the bug. Using radeonfb, my battery was
nearly empty after one night.

Here is my log file :

mar mar 15 11:02:26 CET 2005
before: 34060 mWh
after: 32880 mWh
diff: -1180 mWh
seconds: 1243 sec
result: -3417 mW
Your model seems to be affected.

Does anybody has tried to create a Debian package to test the patches ?

Thanks

Didrik
Comment 77 Adam Glasgall 2005-03-17 17:47:00 UTC
I second <a href="http://bugme.osdl.org/show_bug.cgi?id=3022#c73"> Tim Mann's
comment - I get identical behavior on my 2373-RU1 T40. Even worse, if I add the
radeontool power on/off commands to my ACPI sleep scripts and suspend, when I
resume the screen is filled with red bars, and the system hangs.

However, the whitelist patch works (once I add my model to it).
Comment 78 Mark 2005-04-02 04:38:32 UTC
Someone already asked IBM for help?
Comment 79 Raymond Lai 2005-04-02 12:49:34 UTC
I second http://bugme.osdl.org/show_bug.cgi?id=3022#c78. I think IBM will be
happy to help fix the problems affecting their products.
Comment 80 Dmitriy Zavin 2005-04-22 14:14:47 UTC
Confirming that the whitelist patch works with the IBM T40 237314U after I added
it to the list.

battery.log AFTER the patch was applied.

Fri Apr 22 12:06:04 PDT 2005
before: 52950 mWh
after: 51580 mWh
diff: -1370 mWh
seconds: 7126 sec
result: -692 mW
Congratulations, your model seems NOT to be affected.
Comment 81 Lutisch 2005-04-29 00:56:08 UTC
You compare the XP and Linux uptime from batteries.
The main difference between Linux and XP the CPU speed-step.
On my T41 the minimal CPU frequency under Linux is 600MHz, and under Xp is 300MHz.
I think this is the source of difference between Xp and Linux uptime.
Best Regards,
   Ferenc (yoursoft@freemail.hu)
Comment 82 Lutisch 2005-04-29 00:59:06 UTC
You compare the XP and Linux uptime from batteries.
The main difference between Linux and XP the CPU speed-step.
On my T41 the minimal CPU frequency under Linux is 600MHz, and under Xp is 300MHz.
I think this is the source of difference between Xp and Linux uptime.
Best Regards,
   Ferenc (yoursoft@freemail.hu)
Comment 83 Shaohua 2005-04-30 02:25:05 UTC
>Linux is 600MHz, and under Xp is 300MHz.
Win possibly also does throttling. Linux also can do it, but doesn't show the 
change in cpuinfo.
Comment 84 Thomas Hartwig 2005-04-30 11:11:59 UTC
Hi Lutisch
Comment 85 Thomas M Steenholdt 2005-05-09 14:19:41 UTC
Just wanted to add my figures to the great log...

On my ThinkPad T30 (2366JBG - current latest BIOS, embedded controller firmware)
i get the following numbers with Volker Braun's kernel-T4x-2.6.11.8-23.

normal ACPI S3 sleep (video=radeonfb)
# echo 3 >/proc/acpi/sleep
power consumption ~6.5 W (backlight stays on in this config)

normal ACPI S3 sleep, backlight manually disabled (video=radeonfb)
# radeontool light off
# echo 3 >/proc/acpi/sleep
# radeontool light on
power consumption ~2.4 W

radeon enhanced ACPI S3 sleep (video:radeonfb:force_sleep)
# echo 3 >/proc/acpi/sleep
power consumption ~1080 mW

none of the configurations shows any aparrent stability problems and I think it
should be noted that even though the D2 enabled power consumption is still just
above 1 W, this is a pretty fair number on this machine... APM does not do much
better and it also uses a lot of power when suspending under Windows XP (unsure
if that's APM or ACPI.
Comment 86 Austin Clements 2005-05-25 01:47:38 UTC
The May 20th patch appears to work for the ThinkPad T42 2378-DUU (Gentoo kernel
2.6.11-r4 source package)

Without any patches: 3639 mW

With the May 20th patch forced for the 2378DUU: 781 mW
Comment 87 Borschuk Oleg 2005-06-14 19:02:04 UTC
Patch work for IBM ThinkPad R50 (1829-7RG). Kernel 2.6.11.12.
Thanks for the patch.
Borschuk Oleg.
Comment 88 Chris Carey 2005-06-21 03:32:32 UTC
With regard to speedstep, my T41 will speedstep as low as 50Mhz (as reported by
GKrellM). 600MHz is the lowest I can "force" it to, but it will jump lower. I
have only had this luck with 2.6.10 kernel.

Chris Carey
http://chriscarey.us/hardware/myhardware/thinkpad-t41/
Comment 89 Antti Andreimann 2005-06-28 07:46:51 UTC
Created attachment 5229 [details]
Updated whitelist patch (for 2.6.12)

Updated whitelist patch to apply cleanly to 2.6.12, added all reported 
IDs from this thread.
The patch is over 3 months old by now, and we have 33 whitelist entries.
Maybe it's time to request an inclusion from driver maintainer?
Comment 90 cian cullinan 2005-06-30 03:18:01 UTC
Another one for the whitelist. The patch works on my T42, 2373F6G with power
drain going from ~5W to ~1W.
Comment 91 Doug Frey 2005-06-30 07:35:30 UTC
This patch is working from IBM ThinkPad T40 (2373-19U). For both kernels
2.6.11.8 and 2.6.12.1.  This has been verified on 2 of these laptops.

Thanks,
Doug Frey
Comment 92 Zoltan FARKAS 2005-07-07 04:53:02 UTC
Both patches (2.6.11-rc4 and 2.6.12) are working on a T41 (2373-4QG).

Thank you,

  Zoltan
Comment 93 Grahame Bowland 2005-07-07 11:45:20 UTC
This is working fine on my T41, 23733HM

        {
                /* Reported by Grahame Bowland <grahame@angrygoats.net> */
                .ident = "IBM ThinkPad T41 (2373-3HM)",
                .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "IBM"),
                        DMI_MATCH(DMI_PRODUCT_NAME, "23733HM"),
                },
        },
Comment 94 Brad Langhorst 2005-07-09 11:27:13 UTC
Created attachment 5304 [details]
Added one more system to the whitelist

adds another T40p (2373G1U) to the whitelist
Comment 95 Aivo Pr 2005-07-12 02:51:44 UTC
This is working on my T41 23731FG:
       {
               /* Reported by Aivo Prykk <aivo.prykk@mail.ee> */
               .ident = "IBM ThinkPad T41 (2373-1FG)",
               .matches = {
                       DMI_MATCH(DMI_SYS_VENDOR, "IBM"),
                       DMI_MATCH(DMI_PRODUCT_NAME, "23731FG"),
               },
       },
Comment 96 Volker Braun 2005-07-12 11:28:19 UTC
Created attachment 5318 [details]
Updated whitelist.

Updated whitelist, now contains 49 IBM Thinkpad models. All were reported to
work well. Patch is against linux 2.6.12.2.

Considering the data, it might be safe to enable the patch on all Thinkpads. Is
there a definite reason against that? According to the whitelist, it works on
(some) R40, R50, R51, T30, T40, T40/p, T41, T41/p, T42, X31.
Comment 97 Jürg Billeter 2005-07-12 12:31:35 UTC
Thanks for keeping the patch up-to-date.

When I've tested it about three months ago on a X31 2672-FG4, it broke resuming
AFAIR. But maybe it would be ok to convert the whitelist into a blacklist.
Comment 98 Frank Otto 2005-07-13 11:12:39 UTC
I have just tested the patch on an IBM Thinkpad R32 2658BQG,
it works very well and reduces power consumption in ACPI sleep
by more than a factor 5. Waking up and resuming the X-server
still work fine. Maybe someone can update the patch, I don't
feel qualified to do it. dmidecode says:

Handle 0x0001
        DMI type 1, 25 bytes.
        System Information
                Manufacturer: IBM
                Product Name: 2658BQG
                Version: Not Available

... and so on.
Comment 99 Georges Herber 2005-07-16 12:47:27 UTC
This is working on my R51 1829-9MG:
       {
               /* Reported by Georges Herber <gherber@gmail.com> */
               .ident = "IBM ThinkPad R51 (1829-9MG)",
               .matches = {
                       DMI_MATCH(DMI_SYS_VENDOR, "IBM"),
                       DMI_MATCH(DMI_PRODUCT_NAME, "18299MG"),
               },
       },
Comment 100 gneeki 2005-07-19 15:56:40 UTC
If this patch is the one implemented in the Fedora Core 4 kernel as
linux-2.6.11-radeon-backlight.patch (probably a misnomer) then I can confirm it
works extremely well on my T40 2373-92G with radeonfb:force_sleep.

Before force with 20 minutes S3:
diff: -1500 mWh average loss
After force with 20 minutes S3:
diff: -100 mWh average loss
Comment 101 Chris Vanden Berghe 2005-07-22 00:07:01 UTC
I tried the patch successfully (i.e., the machine still functions correctly) on
a T41 (23739HG).  The improvement in power consumption is less drastic than what
was reported for other machines, though:

Thu Jul 21 20:52:02 CEST 2005
before: 43040 mWh
after: 39730 mWh
diff: -3310 mWh
seconds: 10897 sec
result: -1093 mW
Your model seems to be affected.
Comment 102 Theodore Tso 2005-07-22 14:21:15 UTC
As of 2.6.12.3, it appears to endabling sleep to D2 works _only_ if the radeon
DRM module has never been activiated, at least on my T40p laptop (2373-G1U).  If
you ever start an X.org server with the radeon DRM module available, then even
if you kill the X server and load the radeon.ko module, if you try to suspend to
ram, the machine will never resume.  The sleep ("moon") led will remain lit,
despite toggling the lid switch or hitting the Fn key.  Suspend/resume works
perfectly if you either (a) remove the radeon.ko module from the search path, or
(b) disable to switch to D2 mode.  So it seems that you have your choice of 3D
acceleration or low battery consuption during suspend.   

The current theory is that the Radeon DRM module is doing something strange
which corrupts something the Radeon registers or in the AGP port such that the
BIOS crashes very early in the resume, probably before the kernel gets control
back on the resume.  Ben Herrenschmidt suggested trying an "vbetool post" before
suspending in the hopes this might reset whatever the radeon DRM module had
done, but no luck.  Only removing the D2 patch has fixed the compatibility
problem between the Radeon DRM and suspend-to-ram.
Comment 103 Nils Trebing 2005-07-23 04:10:44 UTC
On my R40 2722-5MG, the patch continues to work fine with 2.6.12.3 and the  
radeon.ko module loaded. I use the X.org packages version 6.8.2-10 from Ubuntu 
5.04. 
Comment 104 Paul Stanisci 2005-07-30 13:17:46 UTC
I just wanted to confirm that I have the same power drain issue on my T41
(2378-DLU) notebook.

When in suspend with ACPI my battery will last at most 12 hours.

Here is my battery.log without the whitelist patch:

---- SNIP ----
Sat Jul 30 09:59:11 EDT 2005
before: 31630 mWh
after: 29160 mWh
diff: -2470 mWh
seconds: 1934 sec
result: -4597 mW
Your model seems to be affected.
----- SNIP ----

Here is my log with the whitelist patch for 2.6.12 (I use kernel version
2.6.12-3). I added my laptop version to the white list since it
was missing.

---- SNIP ----
Sat Jul 30 12:34:48 EDT 2005
before: 31570 mWh
after: 23210 mWh
diff: -8360 mWh
seconds: 8618 sec
result: -3492 mW
Your model seems to be affected.
---- SNIP ----

The difference was only about 1000 mW. This is a far cry from what others have
reported.

As with most others, my laptop's suspend function seems to work properly with
APM. I've had this issue with every 2.6.X kernel I've tried
 (2.6.9, .10 & .12)

~Paul
Comment 105 Marko M 2005-08-04 04:52:19 UTC
After I applied the patch http://bugme.osdl.org/attachment.cgi?id=5229&action=view,
the power consumption of my T41 (2373-2FG) went down to less than 1 watt.

However, on the second suspend, the system will hang, with HDD light and screen
remaining on and CPU apparently at 100% load. Here is my suspend script in
simplified form:

cat > suspend << EOF
#!/bin/sh
/sbin/modprobe -r -s usbhid
/sbin/modprobe -r -s uhci_hcd
/sbin/modprobe -r -s ehci_hcd

sync
/sbin/hwclock --systohc

echo eject > /proc/acpi/ibm/bay
echo 3 > /proc/acpi/sleep

/sbin/modprobe -s ehci_hcd
/sbin/modprobe -s uhci_hcd
/sbin/modprobe -s usbhid

/sbin/hwclock --hctosys
EOF

I haven't tried 2.6.12.3 without the patch, and I haven't tried removing the USB
modules. (I'm not using USB for anything.) My previous kernel was an unpatched
2.6.12.
Comment 106 Paul Stanisci 2005-08-04 06:44:14 UTC
Hello,

I just wanted to post an update to my previous comment (two posts above). I
mistakenly left the FB driver using VESA instead of radeonfb for my second test.
I didn't notice right away since there was a drop in the power drain.

On my T41 (2378-DLU) after applying the patch to 2.6.12.3, the battery drain
dropped pretty dramatically: 

Tue Aug  2 19:00:36 EDT 2005
before: 31700 mWh
after: 31590 mWh
diff: -110 mWh
seconds: 1373 sec
result: -288 mW
Congratulations, your model seems NOT to be affected

Thanks for help everyone. 

~Paul
Comment 107 Nicolas Dufresne 2005-08-06 04:32:44 UTC
The patch works great for my t42.  Here is some new lines you can add to the
whitelist. These are twice the same laptop, first in french and second in English.

+   {
+       /* Reported by Nicolas Dufresne <nicolas.dufresne@usherbrooke.ca> */
+       .ident = "IBM ThinkPad T42 (2378-RBF)",
+       .matches = {
+           DMI_MATCH(DMI_SYS_VENDOR, "IBM"),
+           DMI_MATCH(DMI_PRODUCT_NAME, "2378RBF"),
+       },
+   },
+   {
+       /* Reported by Nicolas Dufresne <nicolas.dufresne@usherbrooke.ca> */
+       .ident = "IBM ThinkPad T42 (2378-RBU)",
+       .matches = {
+           DMI_MATCH(DMI_SYS_VENDOR, "IBM"),
+           DMI_MATCH(DMI_PRODUCT_NAME, "2378RBU"),
+       },
+   },
Comment 108 Wouter Cloetens 2005-08-09 14:24:34 UTC
Created attachment 5565 [details]
Updated whitelist.

Added 2658-BQG from comment 98.
Added 1829-9MG from comment 99.
Added 2373-9HG from comment 101.
Added 2378-DLU from comment 104.
Added 2378-RBF and 2378-RBU from comment 107.
Added my own R51, 1829-EHG.
Sorted list alphabetically to make it easier to check if an entry is already in
the list.

Am I the only one who thinks this is silly? Is there no better way to detect an
affected machine than a whitelist of type/model numbers.
Also, is this the best place to do this? I wasn't using the framebuffer driver.
Comment 109 gneeki 2005-08-09 15:01:54 UTC
Can you add mine please from comment #100 if appropriate? 2373-92G

Agreed, yes it is getting a bit silly.
Comment 110 Wouter Cloetens 2005-08-09 15:08:15 UTC
It's already in the list, that's why I skipped it...
Comment 111 gneeki 2005-08-09 15:18:44 UTC
Ah thanks. Didn't actually look, or see acknowledgement here.
Comment 112 Marko M 2005-08-10 05:55:28 UTC
Update to comment #105: If I switch to text console from X.org before
echo 3 > /proc/acpi/sleep, suspend and resume work without problems. However, I
got a hang after switching to X.org console on /dev/tty7 and attempting to
switch back to /dev/tty1. Unloading all modules before suspending didn't make
any difference. So, it is probably something in X.org (xserver-xorg
6.8.2.dfsg.1-4 in Debian GNU/Linux unstable).
Comment 113 Meik Hellmund 2005-08-14 11:04:43 UTC
here comes another one where the patch is working:


       {
                /* Reported by Meik Hellmund <hellmund@math.uni-leipzig.de> */
                .ident = "IBM ThinkPad R40 (2722-CDG)",
                .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "IBM"),
                        DMI_MATCH(DMI_PRODUCT_NAME, "2722CDG"),
                },
Comment 114 Jürg Billeter 2005-08-21 03:59:30 UTC
Luming, as you've marked this bug as resolved with code fix, could you please
add a comment what patch fixed it and which kernel tree has that patch? Would be
nice to be able to verify that the problem has been solved. Thanks.
Comment 115 Luming Yu 2005-08-21 04:02:19 UTC
Please verify patch mentioned at comment#105
Comment 116 Chris Carey 2005-08-28 20:18:22 UTC
Marked as fixed eh? This patch has never worked for me. Guess I should have
chimed in earlier. Im assuming that I must be doing something wrong if it works
for all of you.

Tried patch 5565 on my Thinkpad 2379-DJU T41, again its not working.
Power consumption is exactly the same as without the patch. Is this patch only
for the built in radeon driver in the kernel? 

Kernel 2.6.12.5
Suspend2 patch
Bootsplash patch
Orinoco patch
radeon osdl #5565 patch
ipw2200 driver (module)
Fglrx video driver (module)

Im going to do my 4th kernel compile today and continue testing...
Comment 117 Antti Andreimann 2005-08-30 12:34:47 UTC
You have to compile radeonfb into kernel or load radeonfb module at boottime.
Either way You MUST be running the console on framebuffer for this patch to have
any effect.
Also look for a line saying something like:
radeonfb: enabling sleep mode
in kernel log. If it's not there, try command line options mentioned in comment#54.
Comment 118 Johannes Hansen 2005-09-13 04:42:14 UTC
Has this been applied to the kernel-tree?
If yes, with what kernel version did it ship?
If no, when/by who will it be applied?
Comment 119 Eugene Pavlovsky 2005-09-26 03:16:10 UTC
pls, add this model to the whitelist
Manufacturer: IBM
Product Name: 1836Q6U
Version: ThinkPad R51
Comment 120 Sten Heinze 2005-10-06 13:22:52 UTC
the patch (id=5565) works on my ThinkPad R51, you can add this model:
Manufacturer: IBM
Product Name: 1829R6G

kernel 2.6.13.2 w/o patch (on debian testing/unstable):
before: 9090 mWh  after: 7320 mWh  diff: -1770 mWh
seconds: 1518 sec
result: -4197 mW

kernel 2.6.13.3 w/ patch:
before: 67600 mWh  after: 67260 mWh  diff: -340 mWh
seconds: 1261 sec
result: -970 mW
Comment 121 eik 2005-10-08 14:47:12 UTC
i have a IBM T40p model 2373-G1A which is not whitelisted yet but works with the
patch from  http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/ applied on a
vanilla 2.6.10 kernel , i couldnt not get the other patches to work even if i
manually added my model to the whitelist.

I think you can add this model to the whitelist or maybe take a look at volkers
patch vs this on e,, also would one contact the radeonfb developer so we can get
a more general solution to the problem.

Also i am willing to try other patches and see if they work even better so
please post them here if you have any. 


System Information
                Manufacturer: IBM
                Product Name: 2373G1A
                Version: ThinkPad T40p

battery.log

Thu Oct  6 22:23:07 GMT 2005
before: 6590 mWh
after: 5820 mWh
diff: -770 mWh
seconds: 2852 sec
result: -971 mW
Congratulations, your model seems NOT to be affected.
Comment 122 Ranjan Grover 2005-10-08 18:26:16 UTC
I was able to make it work with the 2005-08-09 patch on my T42 2378-RRU machine.
Detailed instructions that I used to install linux and get power management to
work may be found here
http://www.thinkwiki.org/wiki/Installing_Debian_sid_on_T42
Comment 123 Chris Frost 2005-11-01 19:45:48 UTC
Created attachment 6444 [details]
Updated whitelist (2379D6U) and linenos (2.6.13.4)
Comment 124 Johannes Hansen 2005-11-02 00:35:49 UTC
Once again I ask:

In which kernel tree is this applied?
Is it applied yet?

I marked resolved it should be applied, else don't mark it as resolved!!
Comment 125 Luming Yu 2005-11-02 00:40:58 UTC
Comment #124 :

I marked this as RESOLVED to notify Len for review and apply.
If the patch shipped, then it marked as CLOSED.
Comment 126 Eugene Pavlovsky 2005-11-07 01:37:44 UTC
pls, add this model to the whitelist
Manufacturer: IBM
Product Name: 1836Q6U
Version: ThinkPad R51
Comment 127 Luming Yu 2005-11-08 08:09:45 UTC
Juha J
Comment 128 Tom Marshall 2005-11-12 10:59:14 UTC
Please add this affected model to whitelist:

ThinkPad T42 2378-XXE (Radeon Mobility M7 7500)

Thanks!
Comment 129 Johannes Hansen 2005-11-13 03:09:47 UTC
T42 2374-CTO
T42 2374-ZEP

Before: 3500 mW
After: 675 mW
Comment 130 Alex Corcoles 2005-11-13 08:23:29 UTC
The following can be whitelisted too:

Manufacturer: IBM
Product Name: 2373VUW
Comment 131 Isaac Wilcox 2005-11-17 12:35:57 UTC
Please *don't* include my e-mail address in radeon_pm.c, but please *do* add 
2373F2G (that's a ThinkPad T42) to the whitelist :) 
 
Cheers, 
 
Isaac Wilcox 
Comment 132 Rushi Bhatt 2005-11-22 08:25:09 UTC
Please add Thinkpad R40, 2722-6YU to whitelist. Works with Ubuntu Breezy kernel
2.6.12-9-686. 

Which kernel version will contain this patch?
Comment 133 Dave Jones 2005-11-29 23:25:35 UTC
Created attachment 6718 [details]
yet another updated patch

FWIW, here's a patch from the Fedora kernel, which includes the above plus a
bunch of others reported in Red Hat bugzilla. (It totals 61 IDs, vs 43 in the
newest patch here)

It also groups them by laptop model to make maintaining it a little easier.
Given the size this thing is growing, I'm a bit concerned about the potential
of this going upstream, though I can't think of a better solution, short of the
kernel providing a 'turn off the lcd' functionality to userspace (which may or
may not work), and move the whitelist there instead as part of the
suspend/resume scripts.
Comment 134 Thomas de Grenier de Latour 2005-11-30 02:27:49 UTC
> Given the size this thing is growing, I'm a bit concerned about the potential
> of this going upstream

Imho, this detailed whitelist approach is a dead end: the patch is already huge,
whereas it doesn't even cover 0.1% of the models which would probably work fine.

Just to give you the idea, there are 1316 models in the "2373*" serie of the T40
family (and there are 5 other series of T40). There are ~12 reports of working
"T40 2373*", and no negative report, so it would sound reasonable to activate D2
for all of them.

I think some kind of whitelist which would match the family (like "Thinkpad T40"
according to `dmidecode -s system-version`) plus the 4 first digits of the
product name ("2373" in my above example) would have more chances to go
somewhere. Maybe with a radeonfb option ("nosleep") which would disable it, just
to be safe.
Comment 135 Volker Braun 2005-11-30 09:18:15 UTC
I know of only one report where the patch actually caused a problem (X crash on
a T42p), and that might have been unrelated to the radeonfb issue. Is it
definitely wrong to enable the patch for all thinkpads? 

Assuming that it is really impossible to enable it for all thinkpads, I think
comment #134 is the way to go.


Comment 136 Thomas de Grenier de Latour 2005-12-01 06:37:28 UTC
I will attach a patch which uses a simplified whitelist. It will enable D2 sleep
for the following ThinkPads: R32, R40, R50, R51, T30, T40p, T40, T41p, T41, T42
and X31. That's all those for which there have been success reports. I've
excluded T42p for now, until more feedback (maybe a call on linux-thinkpad@
would help?).

Also, in addition to the "force_sleep" parameter which still allow testing on
some not-yet-whitelisted models, i've added a "nosleep" parameter which disables
D2 sleep for whitelisted ones in case of trouble.

Comments?
Comment 137 Thomas de Grenier de Latour 2005-12-01 06:40:01 UTC
Created attachment 6734 [details]
Simplified whitelist patch
Comment 138 Peter Fr 2005-12-04 23:43:22 UTC
the simplified whitelist patch does not work for me!

I own a R40 2722B3G

root@todesstern:~# dmidecode |grep R40
root@todesstern:~#

root@todesstern:~# dmidecode |grep Product
Product Name: 2722B3G

thx
Peter
Comment 139 Thomas de Grenier de Latour 2005-12-05 00:32:52 UTC
The "Product" DMI key is not used in this patch (that's the point). Only this
two ones are:
% dmidecode -s system-manufacturer
IBM
% dmidecode -s system-version
ThinkPad T40

Could you check the later returns for you "ThinkPad R40", like i spelled it in
the patch? (i'm sure of the spelling for the models which are also listed in
drivers/hwmon/hdaps.c, but for a few others it was just a random shot)

Also, can you send the output of "dmesg | grep radeonfb" in your current setup
(after a suspend/resume cycle), and the same with the "force_sleep" option
("video=radeonfb:force_sleep,whatever_other_options" boot option)?

For reference, here the former returns:
% dmesg | grep radeonfb
Kernel command line: root=/dev/hda3 resume2=file:/dev/hda3:0x6002 noresume2
video=radeonfb:accel,mtrr,1024x768-32@60 splash=silent,fadein,theme:gentoo
elevator=cfq acpi=noirq console=tty1 quiet
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=260.00 Mhz, System=183.00 MHz
radeonfb: PLL min 12000 max 35000
radeonfb: Monitor 1 type LCD found
radeonfb: Monitor 2 type no found
radeonfb: panel ID string: 1024x768
radeonfb: detected LVDS panel size from BIOS: 1024x768
radeonfb: Dynamic Clock Power Management enabled
radeonfb: IBM ThinkPad T40 detected, enabling D2 sleep
radeonfb (0000:01:00.0): ATI Radeon LW
radeonfb (0000:01:00.0): suspending to state: 2...
radeonfb (0000:01:00.0): switching to D2 state...
radeonfb (0000:01:00.0): resuming from state: 2...
radeonfb (0000:01:00.0): switching to D0 state...

Whereas on an unsupported system (here faked by the "nosleep" option), it whould
more be something like this:
% dmesg | grep radeonfb
Kernel command line: root=/dev/hda3 resume2=file:/dev/hda3:0x6002 noresume2
video=radeonfb:accel,mtrr,1024x768-32@60,nosleep
splash=silent,fadein,theme:gentoo elevator=cfq acpi=noirq console=tty1 quiet
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=260.00 Mhz, System=183.00 MHz
radeonfb: PLL min 12000 max 35000
radeonfb: Monitor 1 type LCD found
radeonfb: Monitor 2 type no found
radeonfb: panel ID string: 1024x768
radeonfb: detected LVDS panel size from BIOS: 1024x768
radeonfb: Dynamic Clock Power Management enabled
radeonfb (0000:01:00.0): ATI Radeon LW
radeonfb (0000:01:00.0): suspending to state: 2...
radeonfb (0000:01:00.0): resuming from state: 2...

Thanks.
Comment 140 Peter Fr 2005-12-05 01:37:41 UTC
Hi,
here is the output of the requested commands:

root@todesstern:~/store# dmidecode -s system-manufacturer
IBM
root@todesstern:~/store# dmidecode -s system-version
Not Available

I think the "Not Available" is responsible for the not working.

radeonfb "old style" patch is working here since 2.6.11 kernel...

thx
Peter
Comment 141 Thomas de Grenier de Latour 2005-12-05 02:15:56 UTC
> root@todesstern:~/store# dmidecode -s system-version
> Not Available

Ok, this explains that. 

Could you attach (or rather email me, because this bug is already noisy enough)
the full output of a "dmidecode"? I'll see if there are other fields which could
be used as a replacement. Otherwise, we can still whitelist R40 based on the 4
digits type code (your "2722"): that would be ~12 entries, so it would be okay i
think, but i have to check first that it can't overlap with other unsupported
models.


> radeonfb "old style" patch is working here since 2.6.11 kernel...

Yep, sure, that i understand, but i still think its a dead-end. We'll never
reach the thousands of entries a complete detailed whitelist would require.
Comment 142 Thomas de Grenier de Latour 2005-12-05 05:14:50 UTC
Created attachment 6771 [details]
radeonfb_d2_suspend-20051205.patch

Ok, new version of the simplified whitelist patch. It adds a macro to register
some models with their 4 digits type code instead of their model name. ThinkPad
R40 is registered this way since its DMI table is incomplete.

Peter, could you try it please? You should get a "radeonfb: IBM ThinkPad R40
(2722) detected, enabling D2 sleep" in your `dmesg | grep radeonfb` if it
works. Thanks.
Comment 143 Peter Fr 2005-12-05 08:09:50 UTC
dmesg from boot:
[42949376.020000] radeonfb: Retreived PLL infos from BIOS
[42949376.020000] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=183.00 Mhz,
System=183.00 MHz
[42949376.020000] radeonfb: PLL min 12000 max 35000
[42949378.660000] radeonfb: Monitor 1 type LCD found
[42949378.660000] radeonfb: Monitor 2 type no found
[42949378.660000] radeonfb: panel ID string: 1024x768
[42949378.660000] radeonfb: detected LVDS panel size from BIOS: 1024x768
[42949378.660000] radeondb: BIOS provided dividers will be used
[42949378.840000] radeonfb: Dynamic Clock Power Management enabled
[42949378.840000] radeonfb: IBM ThinkPad R40 (2722) detected, enabling D2 sleep
[42949378.840000] radeonfb (0000:01:00.0): ATI Radeon LW


dmesg from suspend:
[42949561.250000] radeonfb (0000:01:00.0): suspending to state: 2...
[42949561.250000] radeonfb (0000:01:00.0): switching to D2 state...
[42949588.260000] radeonfb (0000:01:00.0): resuming from state: 2...
[42949588.260000] radeonfb (0000:01:00.0): switching to D0 state...


seems to work fine

thx you very much
Peter
Comment 144 Adam Glasgall 2005-12-10 10:12:49 UTC
My T40 (2373-RU1) also returns "Not Available" for system-version. I'd
appreciate if you could work around it in the new whitelist patch, like you did
with the R40.
Comment 145 Jon Sanchez 2005-12-14 14:16:48 UTC
With the D2 patch applied on a T42 2374-K1G (2.6.15-rc5)

the power usage is  1280mWh at S3 :-(

how do i reach 500mWh ?
Comment 146 Nate Bargmann 2006-01-03 20:14:53 UTC
I manually patched the Debian 2.6.14-7 source with
radeonfb_d2_suspend-20051205.patch and can report that it works on my T42
2373-JTU.  With the patched radeonfb module loaded the power consuption dropped
from 3909 mW to 657 mW while in software suspend (echo -n "mem" > /sys/power/state).

I have Xorg 6.9 and the associated radeon_dri driver loading and noted no ill
effects starting X with the radeon driver specified in Xorg.conf while radeonfb
was loaded.  3D acceleration was unchanged from before and software
suspend/resume worked with the lower power consumption noted earlier.

I strongly urge that this patch be included into the main kernel tree if
possible.  I will continue to test this patch.

Comment 147 ChazeFroy 2006-01-11 02:50:28 UTC
My T30 (2366-QU5) returns "Not Available" for system-version.
Comment 148 Giorgio Lando 2006-01-22 05:23:30 UTC
The 20051205 can be applied cleanly also to vanilla kernel 2.6.15 and has been
included in the archck patchset. In my laptop (a compaq presario 2120EA with a
RADEON IGP 320), the patch (activated with video=radeonfb:force_sleep=1) allows
proper sleep states for the video card.
Comment 149 Charles Curley 2006-02-06 19:59:17 UTC
Please add to the whitelist: Thinkpad R51 1836Q4U.

There is a workaround on this model (ad others) at
http://www.ces.clemson.edu/linux/suspend_mem.shtml.

Thank you.
Comment 150 Martin Grimm 2006-02-07 05:28:37 UTC
radeon_d2_suspend-20051205 only works for me with force_sleep=1 (T41). Kernel is
2.6.13-15.7 from OpenSuSE 10.

From looking at the code and implementation of dmi_system_check() (in
linux/arch/i386/kernel/dmi_scan.c) it looks like dmi_system_check() only counts
matches without a callback_function or with a callback_function returning 0.

radeon_sleep_dmi_whitelisted (The callback-function for matching whitelist
entries) always returns 1. Changing this to 0 fixed it for me.
Comment 151 Derek 2006-02-17 13:46:17 UTC
radeonfb_d2_suspend-20051205.patch

not sure if it's working "right" for me (x32, 2884A2U).

Using

booted with video=radeonfb:force_sleep

radeonfb: forcefully enabling D2 sleep mode

radeonfb (0000:01:00.0): ATI Radeon LY
radeonfb (0000:01:00.0): suspending to state: 2...
radeonfb (0000:01:00.0): switching to D2 state...
radeonfb (0000:01:00.0): resuming from state: 2...
radeonfb (0000:01:00.0): switching to D0 state...

With no radeonfb, I would get numbers from 1170mW, 1234mW, 1322mW, 1019mW

With patched radeonfb, I've gotten 987mW 1097mW.

Wake on LAN is off.  I also replaced sleep call with a shell script that turns
off the backlight.

It sounds almost like mine isn't affected, but I see some of you have gotten
down to 500mW and the script uses 1W as the threshhold and suggests that 500mW
may be a better threshhold.  Anyone else out there have X32 numbers to post?  I
will install winxp to compare my numbers....
Comment 152 Derek 2006-02-17 16:00:50 UTC
roughly 2:47:00 to roughly 3:40:35.
30.16Wh down to 29.75Wh

.883 hours, .41 Wh
Comment 153 Peter Fr 2006-03-24 00:30:56 UTC
Hi, does somebody have an updated patch for 2.6.16 kernel?

I tried to fix the only one hunk, but I don` t think powersaving works as expected.

2.6.15:
result: -759 mW


2.6.16:
result: -1442 mW

Peter
Comment 154 Ari Pollak 2006-03-24 08:15:40 UTC
Created attachment 7661 [details]
Updated patch for 2.6.16
Comment 155 Giorgio Lando 2006-03-24 12:53:58 UTC
I have four hunks rejected with the new patch on vanilla 2.6.16
Comment 156 Konstantin Filtschew 2006-03-24 13:56:41 UTC
same here, the patch was rejected
Comment 157 Jose 2006-03-26 12:16:56 UTC
You can white list: 2373-7FU

Linux 2.6.16-rc4-mm2

It didn't patch cleanly so I had to cut and paste a few lines.
Comment 158 Jon Sanchez 2006-03-26 19:11:48 UTC
patch for 2.6.16 does not work :

patching file drivers/video/aty/radeon_base.c
Hunk #1 FAILED at 273.
Hunk #2 FAILED at 2621.
Hunk #3 FAILED at 2680.
3 out of 3 hunks FAILED -- saving rejects to file
drivers/video/aty/radeon_base.c.rej
patching file drivers/video/aty/radeon_pm.c
Hunk #4 FAILED at 2884.
1 out of 4 hunks FAILED -- saving rejects to file drivers/video/aty/radeon_pm.c.rej




----
why isn't the patch into mainstream kernel??
Comment 159 Giorgio Lando 2006-03-28 13:36:52 UTC
Can someone provide a working patch for 2.6.16? I think that the one above
should be removed.
Comment 160 Giorgio Lando 2006-03-31 05:26:08 UTC
Created attachment 7731 [details]
Correct patch for 2.6.16

This patch for vanilla 2.6.16 applies for me cleanly, and works. Please test
Comment 161 Giorgio Lando 2006-04-15 07:20:47 UTC
I post here again the properly formatted (I hope) patch, as I have submitted to
the kernel maintainer for mainline inclusion. Thanks to Antti Andreimann (the
author), Joel Becker, Volker Braun, Thomas de Grenier de Latour for their help.
Comment 162 Giorgio Lando 2006-04-15 07:23:01 UTC
Created attachment 7877 [details]
radeonfb-2.6.16.patch
Comment 163 Giorgio Lando 2006-04-17 02:50:56 UTC
Created attachment 7886 [details]
radeonfb-2.6.16.patch

Some formal oddities fixed.
Comment 164 Giorgio Lando 2006-04-17 02:55:31 UTC
Created attachment 7887 [details]
radeonfb-2.6.16.patch
Comment 165 Giorgio Lando 2006-04-17 02:59:01 UTC
Created attachment 7888 [details]
radeonfb-D2-2.6.16.patch
Comment 166 Giorgio Lando 2006-04-18 15:01:33 UTC
In order to have this patch included in mainline and the bug solved, we are
trying to reformulate the whitelist of affected models which can solve the issue
with this patch. We think that the best strategy is to identify the affected
models through the subsystem device/vendor IDs, but, for many models actually
listed in the whitelist through their DMI strings, it is not trivial to guess
their subsystem device/vendor IDs. 
So we ask you all to report two data, in order to translate the actual whitelist
in a better one: your thinkpad model: the vendor/device IDs of the graphic
chipset subsystem: please note that these subsystem vendor/device IDs are
different from the graphic chipset PCI vendor/device IDs and identify the final
vendor of the card. Anyway, we need the numerica values. In order to avoid
confusion, we ask you to send us the output of two commands which should give
the data we need:
1) dmidecode -s system-version
2) lspci -d "1002:*" -vn | grep Subsystem

You should have both lspci and dmidecode already installed in your distribution,
otherwise install them.

In order to have faster results, I am going to send you (to all the addresses in
Cc) an email with the same request I am posting here. In order to avoid
confusion, send to my email address patroclo7@gmail.com (and do not post here)
the relevant data. I will collect the data and notify the other people involved
in the revision of the whitelist.
Comment 167 Giorgio Lando 2006-04-19 01:38:28 UTC
Created attachment 7898 [details]
radeonfb-D2-2.6.16.patch
Comment 168 Giorgio Lando 2006-04-19 01:41:52 UTC
Created attachment 7899 [details]
radeonfb-D2-2.6.16.patch

A couple of fixes requested  by the kernel maintainer (thanks to him) are here
addressed. A full revision of the patch by Volker BRaun with a whitelist based
on subsystem vendor/device IDs could be uploaded soon.
Comment 169 Giorgio Lando 2006-05-28 02:49:05 UTC
Created attachment 8219 [details]
patch with a new whitelist

Well, first of all sorry for the delay. I have a new job and I have no more any
laptop affected by the bug, so I am not able to work further on this bug. I
attach the patch with the revised whitelist (by Volker Braun). This is the
opinion by Benjamin Herrenscmidt (the radeonfb kernel maintainer): 

"I think the whitelist should contain the actual PM mode and reinit
function if any so that we can fit the Samsung special case in there
too.

Appart from that, it looks good."

So, if you are able to make this required change, you can submit the patch to
him ( benh@kernel.crashing.org ) for vanilla kernel inclusion (the patch is
already properly formatted, you need only to write a description to make it
perfect). 

I apologize again for the delay, may be that you will not be able to commit it
for 2.6.17 and this will require to adapt slightly the patch (I can help with
this aspect). Contact me for any other issue (but consider that I have no more
the hardware where to test the patch).
Comment 170 Giorgio Lando 2006-05-28 02:51:49 UTC
Created attachment 8220 [details]
patch with a new whitelist

Well, first of all sorry for the delay. I have a new job and I have no more any
laptop affected by the bug, so I am not able to work further on this bug. I
attach the patch with the revised whitelist (by Volker Braun). This is the
opinion by Benjamin Herrenscmidt (the radeonfb kernel maintainer): 

"I think the whitelist should contain the actual PM mode and reinit
function if any so that we can fit the Samsung special case in there
too.

Appart from that, it looks good."

So, if you are able to make this required change, you can submit the patch to
him ( benh@kernel.crashing.org ) for vanilla kernel inclusion (the patch is
already properly formatted, you need only to write a description to make it
perfect and to put the signed off: Antti Andreimann, Thomas de Grenier de
Latour, Volker Braun and myself; you can find the relevant email addresses
inside this bug comments). 

I apologize again for the delay, may be that you will not be able to commit it
for 2.6.17 and this will require to adapt slightly the patch (I can help with
this aspect). Contact me for any other issue (but consider that I have no more
the hardware where to test the patch).
Comment 171 Yang Zhao 2006-06-14 21:29:49 UTC
Any activity on this patch recently?

I'm willing to do the final steps needed to have the patch submitted, but I'm
confused on what it's meant by including "the actual PM mode and reinit
function". What's missing from the whitelist itself, exactly? Or is this
referring to some extra functionality that's yet to be included?
Comment 172 Volker Braun 2006-06-29 13:14:47 UTC
Created attachment 8458 [details]
code improvement, same functionality.

* unified treatment of thinkpads and the samsung P35
* functions and variables renamed to reflect the generalization
* module option name to skip check for device-dependent workarounds: 
  nosleep -> ignore_devlist
Comment 173 Len Brown 2006-08-09 22:28:39 UTC
 moving from ACPI to drivers/video category
Comment 174 Johannes Hansen 2006-08-10 00:18:10 UTC
Any idea when the patch will be shipped?
Its been 2 years since initial bug report... what is the problem?
What need to be done before the patch is ok?
Comment 175 Benjamin Herrenschmidt 2006-08-10 02:16:22 UTC
Real soon now. It should be in -mm now if not already in 2.6.18 (just back from
vacation and I haven't checked)
Comment 176 Volker Braun 2006-08-10 05:24:37 UTC
The patch is in 2.6.18-rc, and will presumably be in the official kernel
starting with 2.6.18
Comment 177 Marko M 2006-10-10 00:42:09 UTC
After upgrading to kernel 2.6.18, my Thinkpad T41 (2373-2FG) hangs on second
suspend. I believe that it is related to this bug fix (see my earlier comments).
Is there some way to troubleshoot this?
Comment 178 Giorgio Lando 2006-10-10 00:58:14 UTC
You can verify that this patch is the cause of your problem (in your previous
post you mentioned an issue with the X server...) disabling it with the boot
parameter:
video=radeonfb:ignore_devlist=1
Comment 179 Marko M 2006-10-10 13:48:02 UTC
With video=radeonfb:ignore_devlist=1, I can suspend multiple times without a
hang, although gnome-power-manager complains about some problem with suspending.

Before rebooting, I also tried the following (without that boot parameter):
/etc/init.d/gdm stop
suspend & resume several times ("echo mem > /sys/power/state")
/etc/init.d/gdm start
attempt to switch virtual consoles -> system hang

Would it be possible to dump the radeon registers before and after suspending?
Maybe the BIOS will initialize the registers on resume differently from
power-on? I have tried some firmware upgrades in the past, but they did not
affect this problem.
Comment 180 Laurent Charrière 2007-01-14 11:00:41 UTC
I'm experiencing the same problem as reported by Marko M
Comment 181 Ranjan Grover 2007-01-18 19:15:13 UTC
Running Debian/Sid
Kernel 2.6.19-2 (self compiled)
xserver-xorg: 7.1.0-11, and xserver-video-ati 6.6.3-2

I would like to report the same problems as #177 and #180. I think the problems 
are more to do with X.org not being able to co-exist with the radeonfb driver. 
If I try to suspend from terminal while X.org is not running, I can suspend 
correctly. However, if X is on, the system hangs on the second suspend. I 
recompiled the kernel and didn't compile radeon in the kernel and I find that 
the system hangs go away but the ACPI sleep drain problems crop up. 
Comment 182 Tabrez Ali 2007-06-05 06:10:00 UTC
I am using 2.6.18 on a X22 Thinkpad 2662-9DU and passing the kernel option
video=radeonfb:force_sleep=1

However my machine still has a high battery drain rate in ACPI suspend as D2
sleep doesnt seem to get enabled. Here is the dmesg output...

  stali@x22:~$ dmesg | grep radeon
  radeonfb (0000:01:00.0): suspending to state: 2...
  radeonfb (0000:01:00.0): resuming from state: 2...

What can I do to fix this issue. And here's my lspci output...

  stali@x22:~$ lspci -d "1002:*" -vn
  0000:01:00.0 0300: 1002:4c59
         Subsystem: 1014:0239
         Flags: bus master, stepping, fast Back2Back, 66MHz, medium devsel,
latency 66, IRQ 11
         Memory at e0000000 (32-bit, prefetchable) [size=128M]
         I/O ports at 2000 [size=256]
         Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
         Expansion ROM at c0120000 [disabled] [size=128K]
         Capabilities: [58] AGP version 2.0
         Capabilities: [50] Power Management version 2

Thank You
Comment 183 Tabrez Ali 2007-06-05 11:08:56 UTC
I was able to fix the problem by tweaking radeon_pm.c and adding my model (IBM
X22 2662-9DU) in the whitelist alongwith PCI_VENDOR_ID_IBM, 0x0239.

Apparently using the force_sleep parameter wasnt helpful with 2.6.18.
Comment 184 Laurent Charrière 2008-07-17 15:55:38 UTC
If anybody is still reading this, my suspend problem (comment #180) seemed to be solved when I switched to the ati driver in Xorg.conf.

Nowadays (ati driver 6.9.0.1, kernel 2.25) I just let the X server figure out which driver to use. The laptop suspends works fine, and the power drain is minimal (300 mW). I assume that all problems related to this bug have, finally, been fixed.

Note You need to log in before you can comment on or make changes to this bug.