ThinkWiki - User contributions [en]

Installing OpenSUSE Leap 42.3 on a ThinkPad T500

2017-11-29T16:54:51Z

Afindlay: Bluetooth

== Model ==
Lenovo Thinkpad {{T500}} 2081-CTO, BIOS 6FET76WW (3.23)

== General ==
I installed {{OpenSUSE}} Leap 42.3 from DVD, selecting the default KDE desktop. Almost everything works as it should, but I did have some problems with the graphics.

== Graphics ==
As [[User:Johnny]] noted in [[Installing OpenSUSE Leap 42.2 on a ThinkPad T500]] the fast GPU consumes too much power (about 7W) so I disabled [[Switchable Graphics]] in the BIOS many years ago and now use just the Intel i965 graphics.

I found that the screen would often stay black after bootup, sometimes with a mouse cursor.
The first workaround that I found was to create {{path|/etc/X11/xorg.conf.d/49-device-intel.conf}} containing this:

<pre>
Section "Device"
Identifier "Intel Graphics"

Driver "modesetting"
Option "AccelMethod" "uxa"
Option "DRI" "3"
Option "Backlight" "intel_backlight"
EndSection
</pre>

The effect is to swap from the ''glamor'' accelerator to ''uxa'' - this makes the graphics usable, but I found that the bottom of the screen jumped occasionally (as if the screen has lost sync with the graphics chip).
A better solution was to remove that file again and to install a much newer kernel. The reasoning here is that the ''modesetting'' driver got some important fixes upstream after Leap 42.3 was frozen for release. I chose to use the HEAD kernel. The process to do it is described here: https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.tuning.multikernel.html and it goes something like this:

<pre>
zypper ar http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ kernel-repo
zypper ref
cd /; tar cf /root/boot-backup.tar boot
zypper install kernel-default-4.14.2-2.1.g56423d9
</pre>

That gave me kernel ''4.14.2-2.g56423d9-default'' and the graphics has been stable ever since.

== Specific Features ==

* Suspend to RAM works out of the box.
* WiFi is OK (though it helps to get a simple form of Kwallet to unlock at login time - see https://gist.github.com/Trucido/b788017a18e1189e6703e42315e8829c)
* Ethernet is OK
* Internal Graphics (Intel) is OK with the newer kernel
* USB is OK
* Bluetooth is OK
* Camera is OK
* Sound is OK
* Plays videos and DVDs if the relevant codecs are installed (See https://opensuse-community.org/)
* Touchpad is OK (though I always disable most of the features to avoid accidental actions)
* VMWare 12 runs OK though you will need the patches here: http://www.hendrik-woltersdorf.de/linux/vmware/vmware_player_12.5.7_patched_mods_for_os_42.3.zip
* VMWare Workstation 14.x will '''not''' work on this hardware. It needs a more recent CPU.

Installing OpenSUSE Leap 42.3 on a ThinkPad T500

2017-11-29T16:51:10Z

Afindlay: Specific features

== Model ==
Lenovo Thinkpad {{T500}} 2081-CTO, BIOS 6FET76WW (3.23)

== General ==
I installed {{OpenSUSE}} Leap 42.3 from DVD, selecting the default KDE desktop. Almost everything works as it should, but I did have some problems with the graphics.

== Graphics ==
As [[User:Johnny]] noted in [[Installing OpenSUSE Leap 42.2 on a ThinkPad T500]] the fast GPU consumes too much power (about 7W) so I disabled [[Switchable Graphics]] in the BIOS many years ago and now use just the Intel i965 graphics.

I found that the screen would often stay black after bootup, sometimes with a mouse cursor.
The first workaround that I found was to create {{path|/etc/X11/xorg.conf.d/49-device-intel.conf}} containing this:

<pre>
Section "Device"
Identifier "Intel Graphics"

Driver "modesetting"
Option "AccelMethod" "uxa"
Option "DRI" "3"
Option "Backlight" "intel_backlight"
EndSection
</pre>

The effect is to swap from the ''glamor'' accelerator to ''uxa'' - this makes the graphics usable, but I found that the bottom of the screen jumped occasionally (as if the screen has lost sync with the graphics chip).
A better solution was to remove that file again and to install a much newer kernel. The reasoning here is that the ''modesetting'' driver got some important fixes upstream after Leap 42.3 was frozen for release. I chose to use the HEAD kernel. The process to do it is described here: https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.tuning.multikernel.html and it goes something like this:

<pre>
zypper ar http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ kernel-repo
zypper ref
cd /; tar cf /root/boot-backup.tar boot
zypper install kernel-default-4.14.2-2.1.g56423d9
</pre>

That gave me kernel ''4.14.2-2.g56423d9-default'' and the graphics has been stable ever since.

== Specific Features ==

* Suspend to RAM works out of the box.
* WiFi is OK (though it helps to get a simple form of Kwallet to unlock at login time - see https://gist.github.com/Trucido/b788017a18e1189e6703e42315e8829c)
* Ethernet is OK
* Internal Graphics (Intel) is OK with the newer kernel
* USB is OK
* Camera is OK
* Sound is OK
* Plays videos and DVDs if the relevant codecs are installed (See https://opensuse-community.org/)
* Touchpad is OK (though I always disable most of the features to avoid accidental actions)
* VMWare 12 runs OK though you will need the patches here: http://www.hendrik-woltersdorf.de/linux/vmware/vmware_player_12.5.7_patched_mods_for_os_42.3.zip
* VMWare Workstation 14.x will '''not''' work on this hardware. It needs a more recent CPU.

Installing OpenSUSE Leap 42.3 on a ThinkPad T500

2017-11-29T16:41:57Z

Afindlay: Fixing the graphics problem

== Model ==
Lenovo Thinkpad {{T500}} 2081-CTO, BIOS 6FET76WW (3.23)

== General ==
I installed {{OpenSUSE}} Leap 42.3 from DVD, selecting the default KDE desktop. Almost everything works as it should, but I did have some problems with the graphics.

== Graphics ==
As [[User:Johnny]] noted in [[Installing OpenSUSE Leap 42.2 on a ThinkPad T500]] the fast GPU consumes too much power (about 7W) so I disabled [[Switchable Graphics]] in the BIOS many years ago and now use just the Intel i965 graphics.

I found that the screen would often stay black after bootup, sometimes with a mouse cursor.
The first workaround that I found was to create {{path|/etc/X11/xorg.conf.d/49-device-intel.conf}} containing this:

<pre>
Section "Device"
Identifier "Intel Graphics"

Driver "modesetting"
Option "AccelMethod" "uxa"
Option "DRI" "3"
Option "Backlight" "intel_backlight"
EndSection
</pre>

The effect is to swap from the ''glamor'' accelerator to ''uxa'' - this makes the graphics usable, but I found that the bottom of the screen jumped occasionally (as if the screen has lost sync with the graphics chip).
A better solution was to remove that file again and to install a much newer kernel. The reasoning here is that the ''modesetting'' driver got some important fixes upstream after Leap 42.3 was frozen for release. I chose to use the HEAD kernel. The process to do it is described here: https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.tuning.multikernel.html and it goes something like this:

<pre>
zypper ar http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ kernel-repo
zypper ref
cd /; tar cf /root/boot-backup.tar boot
zypper install kernel-default-4.14.2-2.1.g56423d9
</pre>

That gave me kernel ''4.14.2-2.g56423d9-default'' and the graphics has been stable ever since.

== Power Management ==
Suspend to RAM works out of the box.

Installing OpenSUSE Leap 42.3 on a ThinkPad T500

2017-11-29T16:17:00Z

Afindlay: Notes on Leap 42.3 on T500

User:Afindlay

2017-11-29T15:51:15Z

Afindlay: Updated ThinkPad

=== Andrew Findlay ===

I am an independent consultant specialising in the design and management of large-scale computer systems, networks, and directories.
I am based in the Thames Valley area of the UK (about 20km west of Heathrow Airport).
I have been a Unix user since about 1985, and largely Linux since 2000.

My day-to-day working environment is an IBM ThinkPad T500 running openSuSE Leap 42.3

Mail: andrew.findlay@skills-1st.co.uk

[[http://www.andrew.findlay.org/ My personal pages]]

[[http://www.skills-1st.co.uk/ My business pages]]

User:Afindlay

2007-01-11T20:04:24Z

Afindlay:

=== Andrew Findlay ===

I am an independent consultant specialising in the design and management of large-scale computer systems, networks, and directories.
I am based in the Thames Valley area of the UK (about 20km west of Heathrow Airport).
I have been a Unix user since about 1985, and largely Linux since 2000.

My day-to-day working environment is an IBM ThinkPad R51 running openSuSE 10.2

Mail: andrew.findlay@skills-1st.co.uk

[[http://www.andrew.findlay.org/ My personal pages]]

[[http://www.skills-1st.co.uk/ My business pages]]

User:Afindlay

2007-01-11T20:02:19Z

Afindlay:

=== Andrew Findlay ===

I am an independent consultant specialising in the design and management of large-scale computer systems, networks, and directories.
I am based in the Thames Valley area of the UK (about 20km west of Heathrow Airport).
I have been a Unix user since about 1985, and largely Linux since 2000.

My day-to-day working environment is an IBM ThinkPad running openSuSE 10.2

Mail: andrew.findlay@skills-1st.co.uk

[[http://www.andrew.findlay.org/ My personal pages]]

[[http://www.skills-1st.co.uk/ My business pages]]

Problem with high power drain in ACPI sleep

2007-01-11T20:00:22Z

Afindlay: /* openSuSE */ corrected link markup

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
==Problem description==
Several people realized that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.
|}

==Affected Models==
{| border="1" cellspacing="0" cellpadding="2" style="float:right;margin-left:20px;"
|-
! style="vertical-align:top;background-color:#ffcfbc;" | affected models
! style="vertical-align:top;background-color:#cfefcf;" | unaffected models
|-
| style="vertical-align:top;background-color:#fff0e0;" |
* {{R32}}
** 2658-BQG
* {{R40}}
** 2722-3GG
** 2722-5MG
** 2722-B3G
** 2722-CDG
** 2897-GWU
** 2722-6YU
** 2722-CDG
* {{R50}}
** 1829-7RG
** 1829-6DM
** 1836-3SU
* {{R51}}
** 1829-9MG
** 1829-EHG
** 1829-L7G
** 1829-R6G
** 1830-DG4
** 1836-Q6U
* {{T23}}
**2647-???
* {{T30}}
** 2366-81A
** 2366-97U
** 2366-FBU
** 2366-96G
*{{T40}}
**2373-19G
**2373-22G
**2373-42G
**2373-75G
**2373-82U
**2373-92U
**2373-A1U
**2373-MU3
*{{T40p}}
**2373-G1U
**2373-G3U
**2373-G3G
**2373-G1G
**2373-G5G
* {{T41}}
**2379-DJU
**2373-3KG
**2373-9HU
**2373-4FG
**2373-4PG
**2373-1FG
**2373-2FG
**2373-2GG
**2373-6U4
**2373-7JU
**2373-CY0
**2373-TG5
**2373-3HM
**2373-4GU
* {{T41p}}
**2373-9FU
* {{T42}}
**2373-C19
**2373-CTO
**2378-DTU
**2378-DUU
**2378-XXE
**2378-R4U
**2373-FWG
**2374-ZEP
**2373-F2G
**2373-JTU
**2373-VUW
**[[2373-6ZG]]
* {{X21}}
**2662-BSG
* {{X32}}
**2884-A3U
*{{X41T}}
** 1869-5CU
| style="vertical-align:top;background-color:#e9f9e9;" |
*[[:Category:A22m | A22m]]
**2628
*[[:Category:A31 | A31]]
**2652-D5G
*[[:Category:R50p | R50p]]
*[[:Category:R52 | R52]]
**1858-6MM
*[[:Category:T41 | T41]]
**2373-GEU
*[[:Category:T41p | T41p]]
**2373-GKG
**2373-GGG
**[[2373-GHG]]
*[[:Category:T42 | T42]]
**[[2373-M1G]]
**[[2373-WBZ]]
**[[2373-F7G]]
**[[2378-DXU]]
**[[2378-FVU]]
**[[2378-RTU]]
**[[2378-RRU]]
*[[:Category:T42p | T42p]]
**[[2373-HTG]]
**[[2373-W6M]]
**[[2373-GTG]]
**[[2373-GXG]]
**2373-KXM
*[[:Category:T43 | T43]]
**[[2668-W12]]
*[[:Category:T43p | T43p]]
**[[2668-G2G]]
*[[:Category:X40 | X40]]
**2371
|}
*Different symptoms have been reported for different models. In some models the origin of the power drain is obvious ([[Problem with LCD backlight remaining on during ACPI sleep|backlight on during suspend]]), in other models there is no obvious reason.

*On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.

*The T4x ThinkPad series and other Radeon based models suspend to ram just fine, and there are no components that are obviously left powered up. The [[UltraBay]] and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF). For these models the higher power drain is caused by a driver problem and can be fixed in software. Starting with linux 2.6.18 this fix is in the official kernel.

The table on the right gives an overview of the models suffering from the mysterious power drain. To find out about your model, you may use the following [[ACPI sleep power drain test script | script]]. It creates a file {{path|/var/log/battery.log}} which will tell you if you are affected or not.

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

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

===Status===
*The official bugzilla entry for the radeon suspend issue is in the [http://bugme.osdl.org/show_bug.cgi?id=3022 OSDL Bugzilla]. There you can find the above-mentioned patch for older kernel versions. The patch removes the CONFIG_PPC_PMAC condition for enabling D2 sleep in {{path|drivers/video/aty/radeon_pm.c}}. If you suspect that this patch makes things worse, you can disable it by the kernel parameter {{bootparm|video|radeonfb:ignore_devlist|1}}. Similarly, if the patch is not automatically activated on your notebook you can force it by {{bootparm|video|radeonfb:force_sleep|1}}. In case that improves your sleep, please leave a note in the bugzilla including the output of {{cmdroot|lspci -d "1002:*" -vn}}. See also [http://thread.gmane.org/gmane.linux.hardware.thinkpad/25355 the linux-thinkpad ML post requesting this information] for more information.

*Most certainly, the DSDT is not at fault. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)

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

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

====Problem with radeonfb and X====
In some cases [[radeonfb]] cannot coexist with the [[radeon]] X.org driver (causing corrupted rendering and hangs). Using the <tt>Option "UseFBDev" "True"</tt> of [[radeon]] may help, but this is incompatible with [[radeon]]'s mergedfb mode. A "GPU device layer" architecture which may, one day, resolve this was proposed by Dave Airlie [http://airlied.livejournal.com/#item30632 here] and [http://lkml.org/lkml/2006/7/22/45 here].
{{HELP|Practical solutions for this problem are needed}}

Configurations which exhibit this problem: {{T43}} [[ATI Mobility Radeon X300]] with {{Fedora}} 5 using the [[radeon]] driver, with and without DRI.

Configurations which don't exhibit this problem: {{T41}} [[ATI Mobility Radeon 9000]] running {{Fedora}} 5 and 6 using [[radeon]] driver, with and without DRI.

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

====openSuSE====
* openSuSE 10.2: Ships with kernel >= 2.6.18. Needs initrd and boot menu changes. See [[http://en.opensuse.org/SDB:ThinkPadPowerDrain openSuSE SDB article on ThinkPad power drain problem]]

====testing radeonfb without changing initrd====
If you want to try the radeon frame buffer, you can enable it as follows:
*First, switch to a console ({{key|Ctrl}}{{key|Alt}}{{key|F1}}) and log in as root.
*Stop X: {{cmdroot|init 3}}
*Now you can load the module: {{cmdroot|1=modprobe radeonfb force_sleep=1}}
*Finally, resume X: {{cmdroot|init 5}}

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

====including radeonfb into your initrd====
As an alternative you can build your customized initrd. This is as simple as running
:{{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> `uname -r`}}
and replacing the initrd in {{path|/boot/grub/grub.conf}} with your new one. You also need to add the kernel command line argument {{bootparm|video|2=radeonfb:force_sleep}}.

With FC6 and KDE I had to:
*Login as root
*Enter the command as {{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> <kernel version>}}
:e.g. {{cmdroot|1=mkinitrd --with=radeonfb /boot/initrd-2.6.18-1.2798.fc6-my.img 2.6.18-1.2798.fc6}}
:And the kernel command line argument was added to /etc/sysconfig/grub.

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

===Notes for gnome-power-manager===
If you suspend from Gnome and need to run radeontool to turn the backlight off you need to find the suspend script for HAL. In Ubuntu, the scripts are located in /usr/share/hal/scripts/. Add the following the script "hal-system-power-suspend":
chvt 1
radeontool light off
And in the resume script ("restore-after-standby"):
radeontool light on
chvt 7

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

===For models without Radeon graphics===
The Problem seems to be solved when you use the [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to turn the LCD off before suspending ...
:{{cmdroot|vbetool dpms off}}
and turning it on afterwards again...
:{{cmdroot|vbetool dpms on}}
You have to change to a normal console before turning the LCD off.
Additionally you have to deactivate the Wake-On-Lan feature like mentioned above ...
:{{cmdroot|ethtool -s eth0 wol d}}
With these commands used together the "testing script" reports no high power drain while suspending.

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

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

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

===R51: Ultrabay and networking===
On my system, ultrabay and networking light were still on while in S3. So were the devices theirselves.
echo -n eject > /proc/acpi/ibm/bay # Disable ultrabay
ethtool -s eth0 wol d # Disable Wake-On-Lan (And so the eth-adaptor)
echo mem > /sys/power/state # Sleep

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

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

===Wake-on-LAN===
Some additional power savings can be achieved by turning off the wake-on-lan ({{cmdroot|ethtool -s eth0 wol d}}). The power drain of the wol feature is far smaller than the radeon bug, but can be noticeable.

Problem with high power drain in ACPI sleep

2007-01-11T19:59:10Z

Afindlay: Link to openSuSE SDB article

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
==Problem description==
Several people realized that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.
|}

==Affected Models==
{| border="1" cellspacing="0" cellpadding="2" style="float:right;margin-left:20px;"
|-
! style="vertical-align:top;background-color:#ffcfbc;" | affected models
! style="vertical-align:top;background-color:#cfefcf;" | unaffected models
|-
| style="vertical-align:top;background-color:#fff0e0;" |
* {{R32}}
** 2658-BQG
* {{R40}}
** 2722-3GG
** 2722-5MG
** 2722-B3G
** 2722-CDG
** 2897-GWU
** 2722-6YU
** 2722-CDG
* {{R50}}
** 1829-7RG
** 1829-6DM
** 1836-3SU
* {{R51}}
** 1829-9MG
** 1829-EHG
** 1829-L7G
** 1829-R6G
** 1830-DG4
** 1836-Q6U
* {{T23}}
**2647-???
* {{T30}}
** 2366-81A
** 2366-97U
** 2366-FBU
** 2366-96G
*{{T40}}
**2373-19G
**2373-22G
**2373-42G
**2373-75G
**2373-82U
**2373-92U
**2373-A1U
**2373-MU3
*{{T40p}}
**2373-G1U
**2373-G3U
**2373-G3G
**2373-G1G
**2373-G5G
* {{T41}}
**2379-DJU
**2373-3KG
**2373-9HU
**2373-4FG
**2373-4PG
**2373-1FG
**2373-2FG
**2373-2GG
**2373-6U4
**2373-7JU
**2373-CY0
**2373-TG5
**2373-3HM
**2373-4GU
* {{T41p}}
**2373-9FU
* {{T42}}
**2373-C19
**2373-CTO
**2378-DTU
**2378-DUU
**2378-XXE
**2378-R4U
**2373-FWG
**2374-ZEP
**2373-F2G
**2373-JTU
**2373-VUW
**[[2373-6ZG]]
* {{X21}}
**2662-BSG
* {{X32}}
**2884-A3U
*{{X41T}}
** 1869-5CU
| style="vertical-align:top;background-color:#e9f9e9;" |
*[[:Category:A22m | A22m]]
**2628
*[[:Category:A31 | A31]]
**2652-D5G
*[[:Category:R50p | R50p]]
*[[:Category:R52 | R52]]
**1858-6MM
*[[:Category:T41 | T41]]
**2373-GEU
*[[:Category:T41p | T41p]]
**2373-GKG
**2373-GGG
**[[2373-GHG]]
*[[:Category:T42 | T42]]
**[[2373-M1G]]
**[[2373-WBZ]]
**[[2373-F7G]]
**[[2378-DXU]]
**[[2378-FVU]]
**[[2378-RTU]]
**[[2378-RRU]]
*[[:Category:T42p | T42p]]
**[[2373-HTG]]
**[[2373-W6M]]
**[[2373-GTG]]
**[[2373-GXG]]
**2373-KXM
*[[:Category:T43 | T43]]
**[[2668-W12]]
*[[:Category:T43p | T43p]]
**[[2668-G2G]]
*[[:Category:X40 | X40]]
**2371
|}
*Different symptoms have been reported for different models. In some models the origin of the power drain is obvious ([[Problem with LCD backlight remaining on during ACPI sleep|backlight on during suspend]]), in other models there is no obvious reason.

*On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.

*The T4x ThinkPad series and other Radeon based models suspend to ram just fine, and there are no components that are obviously left powered up. The [[UltraBay]] and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF). For these models the higher power drain is caused by a driver problem and can be fixed in software. Starting with linux 2.6.18 this fix is in the official kernel.

The table on the right gives an overview of the models suffering from the mysterious power drain. To find out about your model, you may use the following [[ACPI sleep power drain test script | script]]. It creates a file {{path|/var/log/battery.log}} which will tell you if you are affected or not.

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

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

===Status===
*The official bugzilla entry for the radeon suspend issue is in the [http://bugme.osdl.org/show_bug.cgi?id=3022 OSDL Bugzilla]. There you can find the above-mentioned patch for older kernel versions. The patch removes the CONFIG_PPC_PMAC condition for enabling D2 sleep in {{path|drivers/video/aty/radeon_pm.c}}. If you suspect that this patch makes things worse, you can disable it by the kernel parameter {{bootparm|video|radeonfb:ignore_devlist|1}}. Similarly, if the patch is not automatically activated on your notebook you can force it by {{bootparm|video|radeonfb:force_sleep|1}}. In case that improves your sleep, please leave a note in the bugzilla including the output of {{cmdroot|lspci -d "1002:*" -vn}}. See also [http://thread.gmane.org/gmane.linux.hardware.thinkpad/25355 the linux-thinkpad ML post requesting this information] for more information.

*Most certainly, the DSDT is not at fault. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)

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

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

====Problem with radeonfb and X====
In some cases [[radeonfb]] cannot coexist with the [[radeon]] X.org driver (causing corrupted rendering and hangs). Using the <tt>Option "UseFBDev" "True"</tt> of [[radeon]] may help, but this is incompatible with [[radeon]]'s mergedfb mode. A "GPU device layer" architecture which may, one day, resolve this was proposed by Dave Airlie [http://airlied.livejournal.com/#item30632 here] and [http://lkml.org/lkml/2006/7/22/45 here].
{{HELP|Practical solutions for this problem are needed}}

Configurations which exhibit this problem: {{T43}} [[ATI Mobility Radeon X300]] with {{Fedora}} 5 using the [[radeon]] driver, with and without DRI.

Configurations which don't exhibit this problem: {{T41}} [[ATI Mobility Radeon 9000]] running {{Fedora}} 5 and 6 using [[radeon]] driver, with and without DRI.

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

====openSuSE====
* openSuSE 10.2: Ships with kernel >= 2.6.18. Needs initrd and boot menu changes. See [[http://en.opensuse.org/SDB:ThinkPadPowerDrain|openSuSE SDB article on ThinkPad power drain problem]]

====testing radeonfb without changing initrd====
If you want to try the radeon frame buffer, you can enable it as follows:
*First, switch to a console ({{key|Ctrl}}{{key|Alt}}{{key|F1}}) and log in as root.
*Stop X: {{cmdroot|init 3}}
*Now you can load the module: {{cmdroot|1=modprobe radeonfb force_sleep=1}}
*Finally, resume X: {{cmdroot|init 5}}

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

====including radeonfb into your initrd====
As an alternative you can build your customized initrd. This is as simple as running
:{{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> `uname -r`}}
and replacing the initrd in {{path|/boot/grub/grub.conf}} with your new one. You also need to add the kernel command line argument {{bootparm|video|2=radeonfb:force_sleep}}.

With FC6 and KDE I had to:
*Login as root
*Enter the command as {{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> <kernel version>}}
:e.g. {{cmdroot|1=mkinitrd --with=radeonfb /boot/initrd-2.6.18-1.2798.fc6-my.img 2.6.18-1.2798.fc6}}
:And the kernel command line argument was added to /etc/sysconfig/grub.

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

===Notes for gnome-power-manager===
If you suspend from Gnome and need to run radeontool to turn the backlight off you need to find the suspend script for HAL. In Ubuntu, the scripts are located in /usr/share/hal/scripts/. Add the following the script "hal-system-power-suspend":
chvt 1
radeontool light off
And in the resume script ("restore-after-standby"):
radeontool light on
chvt 7

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

===For models without Radeon graphics===
The Problem seems to be solved when you use the [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to turn the LCD off before suspending ...
:{{cmdroot|vbetool dpms off}}
and turning it on afterwards again...
:{{cmdroot|vbetool dpms on}}
You have to change to a normal console before turning the LCD off.
Additionally you have to deactivate the Wake-On-Lan feature like mentioned above ...
:{{cmdroot|ethtool -s eth0 wol d}}
With these commands used together the "testing script" reports no high power drain while suspending.

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

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

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

===R51: Ultrabay and networking===
On my system, ultrabay and networking light were still on while in S3. So were the devices theirselves.
echo -n eject > /proc/acpi/ibm/bay # Disable ultrabay
ethtool -s eth0 wol d # Disable Wake-On-Lan (And so the eth-adaptor)
echo mem > /sys/power/state # Sleep

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

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

===Wake-on-LAN===
Some additional power savings can be achieved by turning off the wake-on-lan ({{cmdroot|ethtool -s eth0 wol d}}). The power drain of the wol feature is far smaller than the radeon bug, but can be noticeable.