Bug 3022
|
Description
Volker Braun
2004-07-06 07:45:51 UTC
The same problem also exists on R40 models. FWIW, the green indicator light on the CD drive stays on while suspended. 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. 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. 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. Created attachment 3397 [details]
proposed patch
Does this patch help a little? Thanks, shaohua
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 ------------ Created attachment 3401 [details]
dmesg output
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. 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. 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. 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? Created attachment 3462 [details]
dmesg output on R40
Created attachment 3463 [details]
output from acpidmp on R40
Created attachment 3464 [details]
dmidecode output on R40
Created attachment 3465 [details]
lspci output on R40
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 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. 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. 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? 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. 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... 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). 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) 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 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. 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 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. 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. 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. 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 Created attachment 4426 [details]
new proposed patch
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. You might want to try 2.6.11-rc1 - that one fixed the black-screen-on-resume for me (IBM ThinkPad X31). 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 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. 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. 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. The patch also works for me. Power consumptions has gone down to 0.8 mW 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. 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! 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. 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 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/ 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. 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. 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. 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.
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 ;) 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. 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 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. --------------------------------------------------------------- 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. 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. 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
Successfully applied patch "Improved whitelist patch" to 2.6.11-rc2-mm1 It works on my ThinkPad T40 model 2373-22G 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 You have to enable radeonfb and apply the patch to check out if it helps. 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? 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. 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. 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. Tried on my R40 2722-3GG, power consumption goes down to 1260 mW/h so this model should be added to the whitelist. 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. 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).
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. 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. 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.
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.
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. 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. 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. 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. 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. 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 :] 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. 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 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). Someone already asked IBM for help? 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. 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. 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) 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) >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.
Hi Lutisch 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. 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 Patch work for IBM ThinkPad R50 (1829-7RG). Kernel 2.6.11.12. Thanks for the patch. Borschuk Oleg. 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/ 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?
Another one for the whitelist. The patch works on my T42, 2373F6G with power drain going from ~5W to ~1W. 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 Both patches (2.6.11-rc4 and 2.6.12) are working on a T41 (2373-4QG). Thank you, Zoltan 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"),
},
},
Created attachment 5304 [details]
Added one more system to the whitelist
adds another T40p (2373G1U) to the whitelist
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"),
},
},
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.
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. 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.
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"),
},
},
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 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. 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.
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. 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 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. 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 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"),
+ },
+ },
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. Can you add mine please from comment #100 if appropriate? 2373-92G Agreed, yes it is getting a bit silly. It's already in the list, that's why I skipped it... Ah thanks. Didn't actually look, or see acknowledgement here. 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). 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"),
},
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. Please verify patch mentioned at comment#105 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... 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. 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? pls, add this model to the whitelist Manufacturer: IBM Product Name: 1836Q6U Version: ThinkPad R51 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 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. 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 Created attachment 6444 [details]
Updated whitelist (2379D6U) and linenos (2.6.13.4)
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 #124 : I marked this as RESOLVED to notify Len for review and apply. If the patch shipped, then it marked as CLOSED. pls, add this model to the whitelist Manufacturer: IBM Product Name: 1836Q6U Version: ThinkPad R51 Juha J Please add this affected model to whitelist: ThinkPad T42 2378-XXE (Radeon Mobility M7 7500) Thanks! T42 2374-CTO T42 2374-ZEP Before: 3500 mW After: 675 mW The following can be whitelisted too: Manufacturer: IBM Product Name: 2373VUW 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 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? 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.
> 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.
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. 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? Created attachment 6734 [details]
Simplified whitelist patch
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 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.
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 > 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. 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.
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 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. 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 ? 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. My T30 (2366-QU5) returns "Not Available" for system-version. 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. 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. 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. 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.... roughly 2:47:00 to roughly 3:40:35. 30.16Wh down to 29.75Wh .883 hours, .41 Wh 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 Created attachment 7661 [details]
Updated patch for 2.6.16
I have four hunks rejected with the new patch on vanilla 2.6.16 same here, the patch was rejected 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. 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?? Can someone provide a working patch for 2.6.16? I think that the one above should be removed. 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
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. Created attachment 7877 [details]
radeonfb-2.6.16.patch
Created attachment 7886 [details]
radeonfb-2.6.16.patch
Some formal oddities fixed.
Created attachment 7887 [details]
radeonfb-2.6.16.patch
Created attachment 7888 [details]
radeonfb-D2-2.6.16.patch
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. Created attachment 7898 [details]
radeonfb-D2-2.6.16.patch
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.
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). 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). 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? 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
moving from ACPI to drivers/video category 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? 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) The patch is in 2.6.18-rc, and will presumably be in the official kernel starting with 2.6.18 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? 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 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.
I'm experiencing the same problem as reported by Marko M 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. 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
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. 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. |