ThinkWiki - User contributions [en]

How to make use of Dynamic Frequency Scaling

2006-01-16T20:17:26Z

134.174.110.5: /* Troubleshooting */

==General==
Linux supports dynamic frequency scaling for systems with the following processors:
*[[Intel Mobile Pentium III]]
*[[Intel Mobile Pentium III-M]]
*[[Intel Mobile Pentium 4]]
*[[Intel Mobile Pentium 4-M]]
*[[Intel Pentium M (Banias)]]
*[[Intel Pentium M (Dothan)]]
*[[Intel Core Solo (Yonah)]]
*[[Intel Core Duo (Yonah)]]
*Mobile Athlon
*AMD64
*Opteron

==Configuring the Kernel==
===2.4 Kernels===
There were various frequency scaling implementations in the 2.4 series of kernels. They all were preliminary and a standard was rised with the introduction of the sysfs filesystem in 2.6 kernels. It is recommended to use a 2.6 kernel, if possible.

===2.6 Kernels===
You need to enable the cpu frequency scaling for your kernel (usually your distros kernel will have this enabled):
:{{kernelconf|CONFIG_CPU_FREQ|<*>|||||}}

You need to enable governors, if not already done in your distros default kernel:
:{{kernelconf|CONFIG_CPU_FREQ_GOV_PERFORMANCE|<*>|||||}}
:{{kernelconf|CONFIG_CPU_FREQ_GOV_POWERSAVE|<*>|||||}}
:{{kernelconf|CONFIG_CPU_FREQ_GOV_USERSPACE|<*>|||||}}

Since 2.6.10 there is the ondemand governor that does cpu frequency scaling in kernel and can be used as an alternative to powernowd etc.
It can be enabled with:
:{{kernelconf|CONFIG_CPU_FREQ_GOV_ONDEMAND|<*>|||||}}

Since 2.6.12 there is the conservative governor that works similar to the ondemand governor.
:{{kernelconf|CONFIG_CPU_FREQ_GOV_CONSERVATIVE|<*>|||||}}

ondemand and conservative differ in the way they scale up and down. The ondemand governor switches to the highest frequency immediately when there is load, while the conservative governor increases frequency step by step. Likewise they behave the other way round for stepping down frequency when the CPU is idle.

==Using the Sys Interface==
The files in {{path|/sys/devices/system/cpu/cpu0/cpufreq/}} provide information and a means of controlling the frequency scaling subsystem.
Seed values are given in Khz. You need to be root to access the /sys filesystem.

Your max speed is at {{path|/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq}}.
:{{cmdroot|cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq}}
:{{cmdresult|700000}}
Your min speed is at {{path|/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq}}.
:{{cmdroot|cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq}}
:{{cmdresult|500000}}
If you are using the userspace governor, you can write to {{path|/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed}} to change the current speed.
:{{cmdroot|echo 700000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed}}
:{{cmdroot|cat /proc/cpuinfo | grep "cpu MHz"}}
:{{cmdresult|cpu MHz : 697.252}}
:{{cmdroot|echo 900000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed}}
:{{cmdroot|cat /proc/cpuinfo | grep "cpu MHz"}}
:{{cmdresult|cpu MHz : 976.152}}

==Using Frequency Scaling Governors==
You can compile the scaling governors into your kernel or compile it as module. You'll find the governors with 'make menuconfig' here:
:{{kernelconf||||CPU Frequency scaling|Power management options (ACPI, APM)|||}}

After booting the new kernel you can get a list of available governors with (as root):
:{{cmdroot|cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors}}
:{{cmdresult|conservative ondemand powersave userspace performance}}

A Short Overview over the available governors:
:;ondemand
::This driver is a dynamic cpufreq policy governor. It changes frequency based on the processor load and may not work on older laptops without Enhanced SpeedStep.
:;conservative
::New since 2.6.12. Similar to ''ondemand''. Optimized for battery powered environments and AMD64. Again, this governor may not work on older ThinkPads like the T21.
:;powersave
::Like the name says, your battery would choose this one ;). It sets the Frequency always to the lowest available.
:;userspace
::You have to choose this one, if you want to set the frequency manually. Some [[#Using Frequency Scaling Daemons|frequency scaling daemons]] require this governor to operate correctly.
:;performance
::This governor sets your Frequency always to the highest available.

Now we set our governor:
What is our current governor?
:{{cmdroot|cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor}}
:{{cmdresult|userspace}}
Set new governor and watch if it has changed
:{{cmdroot|echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor}}
:{{cmdroot|cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor}}
:{{cmdresult|conservative}}

Congrats! Your governor is active.

You may set the governor in your rc.local, to make it used on every boot.

==Using Frequency Scaling Daemons==
Don't forget to enable the userspace governor to have a userspace daemon do the frequency scaling. If it is built as module, load it as <tt>cpufreq-userspace</tt>.

{{NOTE|If your distribution leaves you a choice and you don't intend to do more sofisticated tweaking, it is recommended to use the <tt>ondemand</tt> or <tt>conservative</tt> frequency scaling governors, available in kernels after 2.6.10 or 2.6.12 respectively. See [[#Using Frequency Scaling Governors|above]]. They require less configuration and have generally been experienced to flawlessly adapt to the situations at hand.}}

There are plenty of userspace frequency scaling daemons available:

*[[How to configure cpufreqd | cpufreqd]]
*[[How to configure cpudynd | cpudynd]]
*[[How to configure speedfreqd | speedfreqd]]
*[[How to configure powersaved | powersaved]]
*[[How to configure powernowd | powernowd]]
*[[How to use cpufrequtils | cpufrequtils]]

==Debian notes==
Instead of compiling your own kernel, you can use the {{Debian}} "stock" kernel. In Unstable/SID the 2.6.12 kernel image with an {{path|/etc/modules}} file that includes:

battery
ac
thermal
processor
acpi-cpufreq
cpufreq-userspace

With the powernowd package and you should be setup.

{{Debian}} has no {{path|rc.local}}, so read [http://www.debian.org/doc/FAQ/ch-customizing.en.html#s-custombootscripts this] and [http://www.debian.org/doc/FAQ/ch-customizing.en.html#s-booting this].

A better alternative for Debian than modifying bootscripts, is to install the [http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=sysfsutils sysfsutils package]. Then edit /etc/sysfs.conf (as root), where you can setup values to sysfs entries that you want to be modified automatically on boot.

==Troubleshooting==
*If you have a Coppermine-piix-smi based Thinkpads like from the A2x, X2x and T2x series you need to enable the <tt>speedstep-smi</tt> driver in the kernel and load it if it's built as module. You might want to look at [[How to get SpeedStep working on Coppermine-piix4-smi based Thinkpads | this page]].

*If you have a p4-class celeron based Thinkpad like the R40e you might want to look at [[How to get SpeedStep working on P4-class-Celeron based Thinkpads | this page]]

*You may need to set your BIOS to "maximum performance" if you are using Linux to set the CPU speed. This is necessary to prevent odd behaviour (cpufreq 'freezing' at certain frequencies) with the T4x series.

==Finetuning voltages and available frequencies==
See [[Pentium M undervolting and underclocking]].

[[Category:600X]] [[Category:A20m]] [[Category:A20p]] [[Category:A21e]] [[Category:A21m]] [[Category:A21p]] [[Category:A22e]] [[Category:A22m]] [[Category:A22p]] [[Category:i1200]] [[Category:i1300]] [[Category:i1620]] [[Category:G40]] [[Category:G41]] [[Category:R30]] [[Category:R31]] [[Category:R32]] [[Category:R40]] [[Category:R40e]] [[Category:R50]] [[Category:R50e]] [[Category:R50p]] [[Category:R51]] [[Category:R52]] [[Category:T20]] [[Category:T21]] [[Category:T22]] [[Category:T23]] [[Category:T30]] [[Category:T40]] [[Category:T40p]] [[Category:T41]] [[Category:T41p]] [[Category:T42]] [[Category:T42p]] [[Category:T43]] [[Category:T43p]] [[Category:X20]] [[Category:X21]] [[Category:X22]] [[Category:X23]] [[Category:X24]] [[Category:X30]] [[Category:X31]] [[Category:X32]] [[Category:X40]] [[Category:X41]] [[Category:X41 Tablet]] [[Category:TransNote]]

Talk:How to make use of Dynamic Frequency Scaling

2006-01-16T20:14:49Z

134.174.110.5: /* CPUfreq "stuck" */

== CPUfreq "stuck" ==
Using the "acpi-cpufreq" and "processor" modules, I can use the performance and ondemand governor with great success on a T43, and it switches between 2.1 GHz and ~700 MHz without incident. However, sometimes the processor becomes "stuck" at ~700 MHz, and when I switch to the performance governor "cat /proc/cpuinfo" notes it is still at ~700 MHz.

I have not been able to precisely reproduce these conditions, but they have happened several times. It is cured by a reboot. I'm not running any userspace frequency governers. Anybody else experienced this peculiar behavior? [[User:gsmenden|gsmenden]] 11:20, 10 JAN 2006 (CEST)

----

I had something similar on my T43. It seems that BIOS interfers with cpufreqd's operation. In the end I set BIOS to "maximum performance" when the laptop is on AC, and let cpufreqd keep track of the speed. It seems to work for me (T43, 2669, 2.6.15-kernel)

----
Verfied for my T43. Article amended.

== CPU Speedstep management activation ==
I could not find the "processor" and "acpi-cpufreq" modules, thus leading to an empty /sys/devices/system/cpu/cpu0/ and preventing to set cpu throttling.
I found the speedstep-centrino module which enables the feature.
Environment : X41 (Pentium M), Debian Sid with custom 2.6.12 kernel.
Is the Debian part of the article outdated ?
Hope this helps,
Vincent

== speedstep-smi for T22 ==
I had to use the speedstep-smi driver for my T22, not the speedstep-ich driver as stated in the how-to.
Thomas
----
Yes, it was a mistake. Thanks for the note. [[User:Wyrfel|Wyrfel]] 21:49, 27 Oct 2005 (CEST)
----

== Extremely low freq on a T22 ==

About an hour ago I made Speedstep work on a T22 running Ubuntu Breezy (5.10). Before that I had the machine randomly boot at 700MHz or 900MHz. That is nothing special. But, earlier today, when I booted it, it was running at 187MHz, according to both /proc/cpuinfo and Gnome's CPU frequency applet. It also took about 4 times as long to do some CPU-intensive processing than usually (grepping and sorting a known amount of text), so I'm still thinking that my Thinkpad really was running at 187MHz until I rebooted it.

Has anyone else noticed anything like this? Is there a way to replicate this behavior? Is there a way to "enable" this "step"?

-- _sd
----
Yes, i brought my X20 down to similarly low frequencies also with Ubuntu. I think it's possible through ACPI throttling, but I'm not sure if that was actually how i did it.

[[User:Wyrfel|Wyrfel]] 23:51, 9 Jan 2006 (CET)
----

== Obsolete daemons ==
Removed the note about daemons being obsolete. Using ondemand/conservate is *not* a replacement for daemons, they are generally smarter than a fixed governor and can adapt to different situations better.
----
I reinserted the note, but changed it a little. The point about that note is that most users get good results and less confusion with those two governors. Feel free to extend the section by some remarks about why one might want to use a deamon instead.

[[User:Wyrfel|Wyrfel]] 10:40, 16 January 2006 (CET)
----

Talk:HDAPS

2006-01-14T01:27:49Z

134.174.110.5: HDAPS as joystick

So, this is in the stable kernel now, but what userspace program do we need to actually park the heads?
--[[User:MrStaticVoid|MrStaticVoid]] 01:26, 30 Oct 2005 (CEST)
----
Yes the hdaps driver is in the 2.6.14 kernel, but support to park the heads quickly and freeze the disk queue (to prevent the heads from getting un-parked) is not. There is some disagreement into how that should be implemented.

In other words, the hdaps driver for the moment is rather useless, unless you want to use it to play games.

--[[User:Tonko|Tonko]] 02:10, 30 Oct 2005 (CEST)

----
I head rumours that you can make SDL handle this like a joystick, e.g. for playing Neverball. Can anyone confirm or deny that? Thanx --[[User:Nomeata|Nomeata]] 01:16, 16 Nov 2005 (CET)

Yes it is possible to use it as a joystick, as Tonko allready mentioned.
/dev/input/jsX modprobe joydev

Ozi

Thanks, I didn't have the joydev module. Rebuilding... --[[User:129.13.186.1|129.13.186.1]] 15:30, 16 Nov 2005 (CET)

----
Yeah, it's a pretty good party trick - set up the HDAPS joystick as xmame input. You can play Ms. Pac-man by tilting your laptop to make pac-man navigate the maze. You can imagine that the pac-man "rolls" downhill, just like those old wooden marble-puzzles that you see around. Heh, can actually clear a level or two.

Marble madness was strangely unsatisfying though, and just didn't work well (probably due to the diagonal nature of the screen in that game).

--[[User:gsmenden|gsmenden]] 20:10, 13 Jan 2006 (CEST)

Fglrx

2006-01-11T16:55:59Z

134.174.110.5: /* Packages */

== ATI fglrx driver ==
This is a binary-only driver which supports 3D acceleration.

Home page: https://support.ati.com/ics/support/default.asp?deptID=894&task=knowledge&folderID=356

== Status ==
Current version: 8.20.8 (8th December 2005)

Major changes:
* 8.20.8: fixed resume issues, fixed compile problems with kernels 2.6.13 and 2.6.14
* 8.19.10: has added suspend / resume and dynamic GPU power management support. Using vbetool is no longer required (tested and successful with T43p).

== Known problems and solutions ==
See [[Problems with fglrx]].

== Packages ==
The ATI drivers have explicit permission for repackaging and redistribution of the Linux drivers. Many distributions are supported within the installer, and many more repackaged by external developers. Please visit the [http://wiki.cchtml.com/index.php/Category:Distributions Distribution Page at the Unofficial ATI driver Wiki]

*{{Debian}} packages: http://xoomer.virgilio.it/flavio.stanchina/debian/fglrx-installer.html
** These packages have been added to Debian unstable as "fglrx-driver", so you can now apt-get them and use module-assistant to install (currently v8.20.8-1).
*{{SUSE}} packages: ftp://ftp.suse.com/pub/suse/i386/supplementary/X/ATI/
*{{Gentoo}} {{cmdroot|emerge x11-drivers/ati-drivers}}
*{{Fedora}} packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install kernel-module-fglrx-$(uname -r) ati-fglrx }}
** Creating and installing a custom RPM for a custom-compiled kernel on {{Fedora}}:
# yum install ati-fglrx
# VER=8.20.8.1-0.lvn.1.4 # copy version string from output of above command
# wget http://rpm.livna.org/fedora/4/i386/SRPMS.lvn/ati-fglrx-$VER.src.rpm
# rpmbuild --rebuild --target $(uname -m) --define "ksrc /lib/modules/$(uname -r)/build" --without userland ati-fglrx-$VER.src.rpm
# rpm -Uvh --replacepkgs /usr/src/redhat/RPMS/$(uname -m)/kernel-module-fglrx-$(uname -r)-$VER.$(uname -m).rpm

== User experience ==

How much is the speed gain versus the opensource drivers?

- On the old drivers, I've noticed appx 40% speed gain with ATI fglrx vs open source drivers. However, there are issues with freezing/garbage after suspend, garbage when resizing desktop (ctrl-alt-plus, ctrl-alt-minus), and garbage while using VMware. The current 8.14.13 has shown 400% improvement over using "radeon" or "ati" in xorg.conf. 1200FPS glxgears! (''note that glxgears isnt a benchmark tool, its so simple that its value is without any meaning... you can only compare glxgears using the same drivers/machine, if you change any of then you can have higher/lower values and in real life programs/games happend the opposite. Think in the car engine rpm, higher rpm in the same car usually its a faster car, change anything and its meaningless. ie: gears, truck, wheel size, etc make it useless'')

NOTE: 2D acceleration may be disabled when 3D acceleration is enabled. This comes from the Xorg.conf file the fglrx driver provides
# === OpenGL Overlay ===
# Note: When OpenGL Overlay is enabled, Video Overlay
# will be disabled automatically
Option "OpenGLOverlay" "1"

Just a note to the above. The 2D acceleration for that option refers to video overlay. You can use either regular Xv video overlay or make the video an opengl texture and let the OpenGL engine scale your video. It has nothing to do with 2D drawing primitives. Further, your mileage on performance may vary depending on what card you have. The open-source drivers don't support newer cards, while the ATI drivers don't support older cards.

== Useful links ==
* [http://www.ati.com/products/catalyst/linux.html ATI Linux Driver FAQ]
* [http://www.rage3d.com/content/articles/atilinuxhowto/ ATI Radeon Linux How-To]
* [http://www.rage3d.com/board/forumdisplay.php?f=61&daysprune=30&order=asc&sort=title Rage3D Linux Discussion Forum]
* [http://www.driverheaven.net/forumdisplay.php?f=103 Radeon Driver Forum at Driverheaven]
* [http://odin.prohosting.com/wedge01/gentoo-radeon-faq.html Gentoo ATI Radeon FAQ]
* [http://forums.gentoo.org/viewtopic-t-374745-highlight-t42+ati+dri.html Gentoo T42 ATI. DRI + xorg driver]
* [http://ati.cchtml.com/ Unofficial community ATI bugzilla] - tracks bugs in the driver. Might be monitored by ATI ([http://www.rage3d.com/board/showpost.php?p=1333438751&postcount=386], [http://www.rage3d.com/board/showpost.php?p=1333439009&postcount=390]).

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads:
* [[ATI Mobility FireGL 9000]]
** {{T40p}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility FireGL V3200]]
** {{T43p}}
* [[ATI Mobility Radeon 9000]]
** {{R50}}, {{R51}}
** {{T40}}, {{T41}}, {{T42}}
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility Radeon Xpress 200M]]
** {{R51e}}
* [[ATI Mobility Radeon X600]]
** {{Z60m}}

[[Category:Drivers]]

Problems with fglrx

2006-01-10T21:01:34Z

134.174.110.5: /* Composite Support */

This page discusses issues with the ATI proprietary [[fglrx]] display driver.

== Known Troubles and Solutions ==

=== X-specific issues ===

The current ATI proprietary driver (8.20.8) will work with x.org 6.9. However, if you are running Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install in the normal fashion, force apt to install the driver ignoring dependencies, or simply wait until the debian package maintainer updates the depends requirements.

=== Kernel-specific troubles ===

Using the current ATI driver (8.20.8) with the current release candidate 2.6.15-rc5 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (info stolen from the table below, but put here for better visibility)

=== No hardware acceleration ===
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|fglrx_dri.so}} was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.

To fix this, compile gcc-3.3.5 and copy <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Another possible cause for broken hardware acceleration (2D and 3D) is the radeonfb framebuffer: Switching to vesafb or vesafb-tng is reported to solve the problem on some systems. Also it has proven helpful to not perform {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/etc/modules.autoload/kernel2.x}} at boottime instead.

=== Softlink hell ===

The [[fglrx]] installer replaces the standard X.org OpenGL implementation (Mesa) with its own files, potentially causing collisions with the distribution's file and package management. It is best to install the driver via a package built for your distribution, which will typically include the necessary kludges to make things work. See the [[fglrx]] page for pointers.

====Discussion====

If you install the driver and type "fglrxinfo" which shows you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. I find this *really* frustrating, and do not know why it occasionally occurs -> I think it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to

: cd /usr/X11R6/lib

and list your GL libraries and links

: ls -la *GL*

You should see something like:

: libGL.so -> libGL.so.1.2

and
: libGL.so.1 -> libGL.so.1.2

If you see a link to a mesa library (something like ->libGL.mesa.1.2), then that's your problem! Restore the softlink with a command similar to:
: ln -s <actual file> <softlink name>

e.g.
: ln -s libGL.so.1.2 libGL.so.1

For some reason, this link might "break" later, giving you the software rendering once more. I renamed the mesa library to mesa.bkup, and the system still found it and linked to it despite the name change. If you have to do this a lot, you could write a restoreGL script...

=====Gentoo=====
I did the above steps with no luck but it's working now so read on:

Because
: ldd /usr/X11R6/bin/glxinfo
showed that my system still uses the xorg-x11 mesa think and the above hint didn't work as expected I looked at this:
: libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)
Afterwards I did:
: cd /usr/lib/opengl/xorg-x11/lib/
: mv libGL.so.1.2 libGL.so.1.2_backup
: ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2
After another restart of X "fglrxinfo" showed that it's using the right libs now.

=====Alternative for Gentoo=====
Gentoo has built in tools for managing the OpenGL symlinks. They seem to be replacing the old tool with a new one, so one of the following should work for you:

: # opengl-update ati
: # eselect opengl set ati

Eselect is new, and still ~x86(as of the end of 2005), so you may not have it yet. opengl-update is the old tried-and-true method for managing the symlinks. If opengl-update doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla](assuming they don't know yet)

=== Troubles using software suspend ===
When the computer resumes from suspend, X only displays a garbled image and the computer is frozen.
The problem is acknowledged in ATI's release notes and in knowledge base entry [https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]. Driver version 8.19.10 has "initial support for Suspend and Resume" but is working very nicely for most people (verified on T43, T43p and T42) without vbetool.

If you are using an older version of fglrx, using [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/etc/hibernate/hibernate.conf}}. Be aware though that it breaks suspend/resume for drivers beginning with version 8.19.10, so remember to disable it again when upgrading.

{| cellspacing="0" cellpadding="2" border="1"
|+ tested with the following configurations
!model!!distro||kernel!!fglrx!!PM!!success!!comments
|-
|{{T42}}||SUSE 9.3||2.6.11||8.14.13||swsusp||yes||
|-
|{{T41p}}||???||2.6.14||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch]
|-
|{{T42p}}||Debian||2.6.10||Debian packaged||suspend2||yes||
|-
|{{T43}}||Debian sid||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 (but not earlier versions!)
|-
|{{T43}}||Debian etch||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 and without vbetool
|-
|{{T43}}||Ubuntu Breezy||2.6.12-10||8.19.10||swsusp||yes||Perfect. (Finally.)
|-
|{{T43}}||FC4||2.6.14.1||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.3||8.19.10||suspend2 2.2-rc13||no||DRI enabled
|-
|{{T43}}||FC4||2.6.14.3||8.20.8||suspend2 2.2-rc13||no||DRI enabled
|-
|{{R50p}}||???||???||8.19.10||swsusp||yes||
|-
|{{T43p}}||Debian sid||2.6.14||8.19.10||Suspend to RAM||yes||without vbetool or UseDummyXServer, those two ''break'' the resume process here, with DRI enabled
|-
|{{T43p}}||Debian sid||2.6.14.3||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled
|-
|{{R52}}||Debian sid||2.6.15-rc5||8.20.8||swsup||yes||both vbetool and UseDummyXServer disabled, DRI enabled, needs [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|}

=== Troubles with large RAM ===
Version 8.14.13 (and probably earlier versions) of the driver does not seem to be able to cope with large amounts of RAM: with 512 MB it works, with 1.5 GB it crashes the machine as soon as X is started. The problem is present only if the <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|mem|864m}} kernel parameter.

Version 8.16.20 fixes the problem.

===Display switching ===
The switching between internal and external display doesn't work, because the driver blocks messing around with the chipset via ACPI. If you want to use this feature (i.e. during presentations), you should use the VESA server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20).

===Composite Support===
ATI has not officially supported composite windowing (alpha channel) enabling hardware acclerated translucent windows (primarily for 'eye candy.') Enabling Composite in KDE and the fglrx driver results in a very pretty desktop but unacceptably slow performance on a T43p with ATI's FireGL T2. It is still unusable in its current state (as of driver 8.19.10).

ATI promises support in the future when composite is officially supported by Xorg. Discussion of current status of drivers can be found in the Rage3d forums' (rage3d.com/board) Linux area. Rumor has it that the Microsoft Vista will support composite, so hopefully we will see it before then...

There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 6.9 (as opposed to 6.8.x). Alas, trying this gives better results than the proprietary drivers, but it is still too slow to be reasonably useful.

===Hardlock on X logout===
Up from driver version 8.19.10 you will expierence a system hard lock when logging out from X, if the session manager (kdm/gdm) is not properly configured. You have to tell the session manager to restart X.

In the kdm config file (gentoo: /usr/kde/<VERSION>/share/config/kdm/kdmrc) you have to add following to the section '[X-:*-Core]':

'''TerminateServer=true'''

In the gdm config file add:

'''AlwaysRestartServer=true '''

Information from the ATI butracker: http://ati.cchtml.com/show_bug.cgi?id=239

== Patches ==
The following patches might be needed for certain versions of fglrx.

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]

===fglrx (unspecified old version)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

Problems with fglrx

2006-01-10T21:00:58Z

134.174.110.5: /* X-specific issues */

This page discusses issues with the ATI proprietary [[fglrx]] display driver.

== Known Troubles and Solutions ==

=== X-specific issues ===

The current ATI proprietary driver (8.20.8) will work with x.org 6.9. However, if you are running Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install in the normal fashion, force apt to install the driver ignoring dependencies, or simply wait until the debian package maintainer updates the depends requirements.

=== Kernel-specific troubles ===

Using the current ATI driver (8.20.8) with the current release candidate 2.6.15-rc5 needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (info stolen from the table below, but put here for better visibility)

=== No hardware acceleration ===
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|fglrx_dri.so}} was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.

To fix this, compile gcc-3.3.5 and copy <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.

Another possible cause for broken hardware acceleration (2D and 3D) is the radeonfb framebuffer: Switching to vesafb or vesafb-tng is reported to solve the problem on some systems. Also it has proven helpful to not perform {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/etc/modules.autoload/kernel2.x}} at boottime instead.

=== Softlink hell ===

The [[fglrx]] installer replaces the standard X.org OpenGL implementation (Mesa) with its own files, potentially causing collisions with the distribution's file and package management. It is best to install the driver via a package built for your distribution, which will typically include the necessary kludges to make things work. See the [[fglrx]] page for pointers.

====Discussion====

If you install the driver and type "fglrxinfo" which shows you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. I find this *really* frustrating, and do not know why it occasionally occurs -> I think it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to

: cd /usr/X11R6/lib

and list your GL libraries and links

: ls -la *GL*

You should see something like:

: libGL.so -> libGL.so.1.2

and
: libGL.so.1 -> libGL.so.1.2

If you see a link to a mesa library (something like ->libGL.mesa.1.2), then that's your problem! Restore the softlink with a command similar to:
: ln -s <actual file> <softlink name>

e.g.
: ln -s libGL.so.1.2 libGL.so.1

For some reason, this link might "break" later, giving you the software rendering once more. I renamed the mesa library to mesa.bkup, and the system still found it and linked to it despite the name change. If you have to do this a lot, you could write a restoreGL script...

=====Gentoo=====
I did the above steps with no luck but it's working now so read on:

Because
: ldd /usr/X11R6/bin/glxinfo
showed that my system still uses the xorg-x11 mesa think and the above hint didn't work as expected I looked at this:
: libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)
Afterwards I did:
: cd /usr/lib/opengl/xorg-x11/lib/
: mv libGL.so.1.2 libGL.so.1.2_backup
: ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2
After another restart of X "fglrxinfo" showed that it's using the right libs now.

=====Alternative for Gentoo=====
Gentoo has built in tools for managing the OpenGL symlinks. They seem to be replacing the old tool with a new one, so one of the following should work for you:

: # opengl-update ati
: # eselect opengl set ati

Eselect is new, and still ~x86(as of the end of 2005), so you may not have it yet. opengl-update is the old tried-and-true method for managing the symlinks. If opengl-update doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla](assuming they don't know yet)

=== Troubles using software suspend ===
When the computer resumes from suspend, X only displays a garbled image and the computer is frozen.
The problem is acknowledged in ATI's release notes and in knowledge base entry [https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 737-218]. Driver version 8.19.10 has "initial support for Suspend and Resume" but is working very nicely for most people (verified on T43, T43p and T42) without vbetool.

If you are using an older version of fglrx, using [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/etc/hibernate/hibernate.conf}}. Be aware though that it breaks suspend/resume for drivers beginning with version 8.19.10, so remember to disable it again when upgrading.

{| cellspacing="0" cellpadding="2" border="1"
|+ tested with the following configurations
!model!!distro||kernel!!fglrx!!PM!!success!!comments
|-
|{{T42}}||SUSE 9.3||2.6.11||8.14.13||swsusp||yes||
|-
|{{T41p}}||???||2.6.14||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch]
|-
|{{T42p}}||Debian||2.6.10||Debian packaged||suspend2||yes||
|-
|{{T43}}||Debian sid||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 (but not earlier versions!)
|-
|{{T43}}||Debian etch||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 and without vbetool
|-
|{{T43}}||Ubuntu Breezy||2.6.12-10||8.19.10||swsusp||yes||Perfect. (Finally.)
|-
|{{T43}}||FC4||2.6.14.1||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)
|-
|{{T43}}||FC4||2.6.14.3||8.19.10||suspend2 2.2-rc13||no||DRI enabled
|-
|{{T43}}||FC4||2.6.14.3||8.20.8||suspend2 2.2-rc13||no||DRI enabled
|-
|{{R50p}}||???||???||8.19.10||swsusp||yes||
|-
|{{T43p}}||Debian sid||2.6.14||8.19.10||Suspend to RAM||yes||without vbetool or UseDummyXServer, those two ''break'' the resume process here, with DRI enabled
|-
|{{T43p}}||Debian sid||2.6.14.3||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled
|-
|{{R52}}||Debian sid||2.6.15-rc5||8.20.8||swsup||yes||both vbetool and UseDummyXServer disabled, DRI enabled, needs [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]
|}

=== Troubles with large RAM ===
Version 8.14.13 (and probably earlier versions) of the driver does not seem to be able to cope with large amounts of RAM: with 512 MB it works, with 1.5 GB it crashes the machine as soon as X is started. The problem is present only if the <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|mem|864m}} kernel parameter.

Version 8.16.20 fixes the problem.

===Display switching ===
The switching between internal and external display doesn't work, because the driver blocks messing around with the chipset via ACPI. If you want to use this feature (i.e. during presentations), you should use the VESA server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20).

===Composite Support===
ATI has not officially supported composite windowing (alpha channel) enabling hardware acclerated translucent windows (primarily for 'eye candy.') Enabling Composite in KDE and the fglrx driver results in a very pretty desktop but unacceptably slow performance on a T43p with ATI's FireGL T2. It is still unusable in its current state (as of driver 8.19.10).

ATI promises support in the future when composite is officially supported by Xorg. Discussion of current status of drivers can be found in the Rage3d forums' (rage3d.com/board) Linux area. Rumor has it that the Microsoft Vista will support composite, so hopefully we will see it before then...

===Hardlock on X logout===
Up from driver version 8.19.10 you will expierence a system hard lock when logging out from X, if the session manager (kdm/gdm) is not properly configured. You have to tell the session manager to restart X.

In the kdm config file (gentoo: /usr/kde/<VERSION>/share/config/kdm/kdmrc) you have to add following to the section '[X-:*-Core]':

'''TerminateServer=true'''

In the gdm config file add:

'''AlwaysRestartServer=true '''

Information from the ATI butracker: http://ati.cchtml.com/show_bug.cgi?id=239

== Patches ==
The following patches might be needed for certain versions of fglrx.

===fglrx 8.20.8===

* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]

===fglrx (unspecified old version)===
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug

===fglrx 8.8.25 ===
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]

Talk:Problems with fglrx

2006-01-10T20:55:50Z

134.174.110.5:

== using kernel AGP vs fglrx AGP ==

Anyone know whether this makes a performance and/or stability difference?

== 8.20.8 does work fine with current Debian sid packages ==

<pre>
spiney@t43p:~$ dpkg -l xserver-xorg
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-============================-============================-==================
ii xserver-xorg 6.9.0.dfsg.1-2 the X.Org X server
spiney@t43p:~$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: MOBILITY FireGL V3200 Pentium 4 (SSE2) (FireGL) (GNU_ICD)
OpenGL version string: 1.3.5519 (X4.3.0-8.20.8)
</pre>

--[[User:Spiney|spiney]]
----

Ahh - thanks for the info. You perhaps compiled the modules for the drivers yourself and did not use the debian packaged fglrx-driver? Thus, it must be an unneeded limitation on the debian packaged driver which limits its installation... Full listing at http://packages.debian.org/unstable/x11/fglrx-driver which lists as required packages:

xserver-xorg (<< 6.8.99)
the X.Org X server
xserver-xorg (>= 6.8.0)

The first limitation (<<6.8.99) is what prevents installation. I'm sure I could force apt to install it, but I may go back to compiling the modules myself, as using fglrx 8.20.8 with kernel 2.6.15 needs a small patch to compile correctly anyway... --[[User:gsmenden|gsmenden]]

== Disabling the external VGA port? ==

Does anyone know how disable the VGA port ''completely'' even when a cable is attached? Fiddling around with the DesktopSetup and ForceMonitor options didn't do the trick for me, and the MonitorLayout option found in some documentation is no longer valid in the current fglrx driver.

--[[User:Spiney|spiney]] 19:42, 10 Jan 2006 (CET)
----

Talk:How to make use of Dynamic Frequency Scaling

2006-01-10T16:33:44Z

134.174.110.5:

== CPUfreq "stuck" ==
Using the "acpi-cpufreq" and "processor" modules, I can use the performance and ondemand governor with great success on a T43, and it switches between 2.1 GHz and ~700 MHz without incident. However, sometimes the processor becomes "stuck" at ~700 MHz, and when I switch to the performance governor "cat /proc/cpuinfo" notes it is still at ~700 MHz.

I have not been able to precisely reproduce these conditions, but they have happened several times. It is cured by a reboot. I'm not running any userspace frequency governers. Anybody else experienced this peculiar behavior? [[User:gsmenden|gsmenden]] 11:20, 10 JAN 2006 (CEST)

== CPU Speedstep management activation ==
I could not find the "processor" and "acpi-cpufreq" modules, thus leading to an empty /sys/devices/system/cpu/cpu0/ and preventing to set cpu throttling.
I found the speedstep-centrino module which enables the feature.
Environment : X41 (Pentium M), Debian Sid with custom 2.6.12 kernel.
Is the Debian part of the article outdated ?
Hope this helps,
Vincent

== speedstep-smi for T22 ==
I had to use the speedstep-smi driver for my T22, not the speedstep-ich driver as stated in the how-to.
Thomas
----
Yes, it was a mistake. Thanks for the note. [[User:Wyrfel|Wyrfel]] 21:49, 27 Oct 2005 (CEST)
----

== Extremely low freq on a T22 ==

About an hour ago I made Speedstep work on a T22 running Ubuntu Breezy (5.10). Before that I had the machine randomly boot at 700MHz or 900MHz. That is nothing special. But, earlier today, when I booted it, it was running at 187MHz, according to both /proc/cpuinfo and Gnome's CPU frequency applet. It also took about 4 times as long to do some CPU-intensive processing than usually (grepping and sorting a known amount of text), so I'm still thinking that my Thinkpad really was running at 187MHz until I rebooted it.

Has anyone else noticed anything like this? Is there a way to replicate this behavior? Is there a way to "enable" this "step"?

-- _sd
----
Yes, i brought my X20 down to similarly low frequencies also with Ubuntu. I think it's possible through ACPI throttling, but I'm not sure if that was actually how i did it.

[[User:Wyrfel|Wyrfel]] 23:51, 9 Jan 2006 (CET)
----

Category talk:X60

2006-01-05T16:31:32Z

134.174.110.5:

<nowiki><rant></nowiki>

The new [http://www.notebookreview.com/assets/8714.jpg key layout] is ''evil''.

For crying out loud, with what kind of accuracy do they think I can place my right pinky, with the view obstructed by my palm? It was bad enough when they put {{ibmkey|Backward|#494949}} and {{ibmkey|Forward|#494949}} in the "vacant" space around {{key|Up}}, so that I keep switching pages in my browser when I try to scroll up. But making the right {{key|Ctrl}} and {{key|Alt}} keys narrower than a finger and penalizing any miss with a focus-grabbing {{key|Context}} popup? That's insane.

Oh, yes, I'm sure the Pointy Haired purchasers will love it ("ooh, more keys!"). Those Lenovo engineers, they seem to have lost all dignity when they switched employers.

<nowiki></rant></nowiki> --[[User:Thinker|Thinker]] 14:41, 5 Jan 2006 (CET)
----

Holy cow, I totally agree. I never understand decisions like this, for all you have to do is ask some people that *actually use the laptop* every day and they will tell you why this is bad / good. I just placed a micro-rant about the addition of the Windows keys too. Looks like I'll stay with my good old T43p for a while!

-[[User:gsmenden|gsmenden]] 14:41, 5 Jan 2006 (CET)

Category talk:T60

2006-01-05T16:24:40Z

134.174.110.5:

#@)$(*!!!! From the article:

"The T60 improves upon the T43 by offering... a Windows key"

I've always loved IBM for omitting the Windows key on their keyboards - I'm sure most all of us linux users also agree that this is NOT an improvement. I think that Lenovo is deviating from the original visions/spirit of IBM in several regards...

Talk:Problem with fan noise

2005-11-22T05:26:00Z

134.174.110.5: /* Thinkpad T42 Radeon Mobility M7 */

== Problem with fan noise on R51 1829 L7G (ATI M9) ==

On my R51 the fan is behaving like this:

* > 45C -> fan on;
* < 38C -> fan off.

By using cpufreq + laptop_mode + Xorg DynamicClocks + WiFi power management, I get the fan stopped time to time, but only for 3 minutes time (transition from 38 C -> 45 C). The cooling down cycle is taking 20 minutes in the best case.

I knew about the 'ibm_acpi experimental=1' trick, but in my opinion this is not very useful since nobody can guarantee that a temperature greater then 45 C will not damage the laptop and in the same time the transition time is very short (the laptop gets hot fast without fan).

== Thinkpad T42 Radeon Mobility M7 ==

When Xorg is running, the fan is always on and pretty loud !
Setting DynamicClocks does not help

it's clear that the GPU is the problem on the thinkpad :

after 10minutes with the fan off
temperatures: 44 47 33 52 32 -128 24 -128

1: CPU
2: Mini PCI Module
3: HDD
4: GPU
5: Battery
6: N/A
7: Battery
8: N/A

Controlling the fan speed would be really cool !

What is the maximum temperature not to cross ?
----
Word on the 'net is that 85 degrees is the max operating temp for most of the Intel chips. I've seen some high 70's all the time (just put it on carpet for awhile and play some quake3 :). I wouldn't let your processor get much higher than 85...

----
Older versions of xorg (i.e. 6.7.0) don't seem to be able to use the DynamicClocks option although it's set in the xorg.conf. Search the log to find out if it's really used.

== Thinkpad R32 with Radeon Mobility M6 ==

Updating xorg-x11 from 6.7.0 to 6.8.2 and using Speedstep (with the ondemand module in this case) helped cooling the system down significantly:

* before updating the CPU was ~62 C in idle state, and got very near the critical temperature (72 C) during heavy load - I even got some freezes because of the heat ;)
* after the update the CPU is ~54 C in idle state, and still gets to about 68 C while under heavy load

The second sensor (which may be the GPU) is somehow fixed to 50 C (maybe a bug?)

The fan on the R32 is behaving like this:

* > 61 -> fan in state 2 (quite noisy)
* < 55 -> fan in state 1 (less noisy :) )

But I remember using my old SuSE distribution with kernel 2.4.16, apm and some old x11 version the fan actually stopped completely from time to time.

Concerning the maximum temperature of the CPU, I found that the critical temperature on the R32 for the CPU sensor is 72 C
(using {{cmdroot|cat /proc/acpi/thermal_zone/THM0/trip_points }} )

== Fan Control script: more save version ==

ibm_acpi works well on my R50 and R51. But to rely on it completely, I modified the script in two ways:

1. It catches verious signals and turns the fan on before it quits

2. It turns off the fan under very strict conditions, leaving it on when unexpected errors occur.

Here is my script:

#!/bin/sh

# july 2005 Erik Groeneveld, erik@cq2.nl
# More conservatiev and saver version
# It make sure the fan is on in case of errors
# and only turns it off when all temps are ok.

IBM_ACPI=/proc/acpi/ibm
THERMOMETER=$IBM_ACPI/thermal
FAN=$IBM_ACPI/fan
MAXTRIPPOINT=65
MINTRIPPOINT=60
TRIPPOINT=$MINTRIPPOINT

echo fancontrol: Thermometer: $THERMOMETER, Fan: $FAN
echo fancontrol: Current `cat $THERMOMETER`
echo fancontrol: Controlling temperatures between $MINTRIPPOINT and $MAXTRIPPOINT degrees.

# Make sure the fan is turned on when the script crashes or is killed
trap "echo enable > $FAN; exit 0" HUP KILL INT ABRT STOP QUIT SEGV TERM

while [ 1 ];
do
command=enable
temperatures=`sed s/temperatures:// < $THERMOMETER`
result=
for temp in $temperatures
do
test $temp -le $TRIPPOINT && result=$result.Ok
done
if [ "$result" = ".Ok.Ok.Ok.Ok.Ok.Ok.Ok.Ok" ]; then
command=disable
TRIPPOINT=$MAXTRIPPOINT
else
command=enable
TRIPPOINT=$MINTRIPPOINT
fi
echo $command > $FAN
# Temperature ramps up quickly, so pick this not too large:
sleep 5
done

----
I added this script to the other ones. Don't wander about my talk edits, i didn't realize i was on the talk page. [[User:Wyrfel|Wyrfel]] 01:48, 13 Aug 2005 (CEST)
----

== X41 ==

Same fan problem here on the X41. Once it starts it won't stop (unless it is _very_ cold outside). Undervolting the CPU doesn't help - still the same problem.

== Fan speed control? ==

Only the X31 and X40 have an ACPI method for controlling the FAN speed (this is why ibm_acpi provides this functionality just for these models).

What will happen if we take the "FANS" method from the [http://acpi.sourceforge.net/dsdt/view.php?id=219 X40 DSDT], paste it into a iasl-disassembled DSDT of (say) a T43, recompile it and [http://gaugusch.at/kernel.shtml tell the kernel] to use the patched DSDT? ibm_acpi will present the functionality, but it may or may not work.

--[[User:Thinker|Thinker]] 16:16, 28 Sep 2005 (CEST)

Any risk of damaging the hardware when doing this? E.g. what does occur if the system overheats - will the CPU be destroyed are does it automatically switch of? As I've just bought a new X41 I don't want to take any stupid risks - but otherwise I'd say let's try it out.

--gst Thu Sep 29 18:14:13 CEST 2005

I think Intel CPUs have some built-in thermal protection, but I'd hate to test it. And of course, any fiddling with the hardware at this level might damage it. That said, when the CPU is mostly idle it keeps a reasonable temperature even when the fan is disabled, so as long as you keep an eye on both the CPU usage meter and /proc/acpi/ibm/thermal, things should be pretty safe temperature-wise. For extra safety you can force the CPU to its lowest speed via {{path|/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq}}.
--[[User:Thinker|Thinker]] 18:33, 29 Sep 2005 (CEST)

== Further discussion ==

I've just found a very interesting thread regarding the same issue on HP notebooks. IMO it provides many insight information about heat/fan problems in general, the URL is: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=853249
Especially the posts by the HP engineer "Andy Fisher" are very interesting. IBM should be able to provide the same BIOS fix as HP did (maybe I should have bought an HP notebook instead of a Thinkpad?).

I've also contacted IBM/Lenovo support via the website about the fan issue. Maybe it helps when others do this as well (especially people who bought larger quantities) so that this issue is taken serious by Lenovo. Is there already any official response to this problem?

--gst Thu Sep 29 19:40:34 CEST 2005
----

Two of the changes mentioned by the HP engineer make perfect sense here: raise the low trip points and make speed transition gradual. Oh, and get rid of the annoying beat pattern (a brief speed pulse every few seconds) it sometimes gets into!

But from our perspective, what would probably be best is to do the whole thing in software, providing the flexibility for personal preferences and smart decisions. The hardware would only enforce emergency override or throttle/shutdown for extreme temperatures. Then we could do cute things like having a software daemon lower the thresholds in a noisy environment (as judged using the built-in microphone) or when the laptop is on the user's lap (as judged by the built-in accelometers).

--[[User:Thinker|Thinker]] 18:47, 30 Sep 2005 (CEST)

I noticed that on my T43 the fan is usually in one of two modes, low speed (around 3300 RPM, triggered around CPU=47deg) and medium speed (around 4100 RPM, can't figure out the trip condition). The former is nearly inaudible, but the latter is quite noticable in the absense of strong background noises.

Now, the problem is that once it has tripped into medium speed, it usually never comes back to low speed until the next reboot. So once it happens, to quiet things down I can only run one of the fan-disabling scripts given here. But with a disabled fan the T43 is not thermally stable, so it will spend its time moving back and forth between the hysteresis thresholds, i.e., toggling between 4100 RPM and 0 RPM every few minutes. This is quite silly and annoying, when staying at low speed would be both more stable and more quiet.

I hope someone will find a way to control the fan speed, or at least to reset the embedded controller's hysteresis state.

--[[User:Thinker|Thinker]] 10:29, 6 Oct 2005 (CEST)

When you do changes to e.g. the Energy Schema in Windows or you eject the Thinkpad of the Docking Station it seems that the controllers state is rest. At least on the X41 the fan does stop until it reaches the threshold to start some minutes later. So it should be doable. --85.124.171.70

That's good. But just like a bunch of other functions (e.g., controlling the battery charge threshold), it probably uses low-level undocumented proprietary interfaces which are very hard to figure out without the help of IBM/Lenovo, who are in denial about the whole thing. --[[User:Thinker|Thinker]] 01:40, 16 Oct 2005 (CEST)

----

== Works fine with APM instead of ACPI? ==

On my X41 the fan starts after about 10 minutes of use and doesn't stop (until it is rather cold in my room - and even then it runs most of the time ;) A friend of mine who has a X41 too (though another model) and who does use NetBSD and APM doesn't experience this problem. He claims that the fan only comes up if the system is not idle. So either it is colder in his room, the X41 model which he has doesn't have this flaw or APM does use different tresholds than ACPI.

* Then why not just try the {{bootparm|acpi|off}} kernel parameter and see what happens? --[[User:Thinker|Thinker]] 18:14, 30 Sep 2005 (CEST)

I currently don't have physical access to the X41. Will try in a few days.

== Rewiring the fan? ==

Since IBM/Lenovo shows no intention of fixing their embedded controller firmware or releasing its specs, how about getting the embedded controller out of the loop? I'd be happy as a clam if my fan was hard-wired to work at a constant 3000RPM, with temperatures kept at bay in software through CPU frequenty control.

Assuming the fan has the standard 3-wire connector, we can probaby keep the sensor and ground wires untouched, and rewire the positive wire to some nearby current source of appropriate voltage (through a resistor, for fine-tuning). The trick would be to find an easily tappable source that can handle an extra 2W and has the appropriate voltage (i.e., just slightly higher than what the fan needs to rotate at that RPM, so we don't waste too much energy in the resistor). Any idea what are the typical fan voltages and what would be an appropriate hookup point?

--[[User:Thinker|Thinker]] 01:59, 16 Oct 2005 (CEST)
----

== Secret sensor and the cause of fan always on ==

On my {{T43}}, ecdump offsets 0xC0-0xC2 seem to include 3 more temperature sensors that are not seen in {{path|/proc/acpi/ibm/thermal}}:
# cat /proc/acpi/ibm/thermal;
temperatures: 44 41 33 42 33 -128 30 -128
# perl -ne 'm/^EC 0xc0: .(..) .(..) .(..) / or next; print hex($1)." ".hex($2)." ".hex($3)."\n"' < /proc/acpi/ibm/ecdump
40 48 43

Note the "48" entry (EC offset 0xC1). Something's pretty hot even at full full speed (level 7, 4700RPM). This sensor increases very quickly when the system starts (in fact, faster than anything else when the CPU is undervolted and [[fglrx]] is in maximum powersaving).

Now, note this: the fan kicks up from low speed to medium speed whenever this sensor reaches 46 degrees, even if no other sensor changes; and this seems to usually be the first trigger encountered. Moreover, this sensor hovers around 47-48 degrees even on an idle machine. Taken together, '''this fully explains the "fan always on" behavior: a previously-unnoticed sensor that's always hot.'''

Any idea what this sensor is? It seems correlated with WiFi: there's a 2deg difference when I toggle {{path|/sys/bus/pci/drivers/ipw2200/*/rf_kill}} (without ever being associated so this shouldn't affect anything else), and heavy WiFi data transfer increases temperature by several more degrees. This suggests the sensor is located in or close to the mini-PCI slot (i.e., under the touchpad). That region is indeed often hot to the touch. But why would the mini-PCI slot get so hot? Could it be the southbridge, which sits under the mini-PCI slot with no heatsink and poor ventilation? Can anyone correlate this sensor other specific activity, or with blocking of specific ventilation holes, or with cooling of specific components? If it's the mini-PCI slot? The operating temperature of the Intel 2200BG is [ftp://download.intel.com/network/connectivity/resources/doc_library/tech_brief/2200bg_prodbrief.pdf 0-80 deg].

Caveat: this is my experience with a {{T43}} after [[Pentium M undervolting and underclocking|undervolting]] the CPU and activating [[How to make use of Graphics Chips Power Management features|maximal GPU powersaving using fglrx]]. It could be that for other people, other components are the first to trigger. But either way, those are 3 temperature sensors we didn't know of and they're used by the Embedded Controller's algorithm.

--[[User:Thinker|Thinker]] 16:20, 20 Nov 2005 (CET)
----