[Lenovo Thinkpad x201s] Overheat due to slow fans when on 'auto'

Reported by Jamie Strandboge on 2011-04-05
This bug affects 148 people
Affects Status Importance Assigned to Milestone
linux (Fedora)
linux (Ubuntu)
Andy Whitcroft
Abhishek kumar singh
Andy Whitcroft
Andy Whitcroft
thinkfan (Debian)
Fix Released

Bug Description

On my Thinkpad x201s with an i7, if I utilize all of the CPUs/hyperthreads, the machine can be made to overheat very quickly. This is because of the default level setting of 'auto' in /proc/acpi/ibm/fan. On 'auto', the fan only ever goes up to around 4500rpm, while in 'disengaged' mode it can go as high as 6400rpm. At 4500rpm, the CPU continues to climb until the system is forcibly shutdown at 100C. If I reload thinkpad_acpi like so:
$ sudo rmmod thinkpad_acpi
$ sudo modprobe thinkpad_acpi fan_control=1

Then I can set the fan to disengaged mode manually:
echo "level disengaged" > /proc/acpi/ibm/fan

With this setting, I can utilize all of the CPUs for an extended time and not surpass 85C, still pretty hot but well under the 100C range. Furthermore, setting to level '7' (the supposed max fan speed) runs the fan at ~5300, well below the maximum fan speed.

In maverick this did not seem to be as much of a problem (perhaps because of the lack of the big kernel lock in natty?).

Related bugs:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610722 (against thinkfan package, but demonstrates that other x201 users are having the same problem)

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: linux-image-2.6.38-7-generic 2.6.38-7.39
Regression: Yes
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.38-7.39-generic 2.6.38
Uname: Linux 2.6.38-7-generic x86_64
 Error: command ['gksu', '-D', 'Apport', '--', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 1: GNOME_SUDO_PASS
 Sorry, try again.
 sudo: 3 incorrect password attempts
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Architecture: amd64
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
 /dev/snd/controlC0: jamie 2641 F.... pulseaudio
 /dev/snd/pcmC0D0p: jamie 2641 F...m pulseaudio
CRDA: Error: [Errno 2] No such file or directory
 Card hw:0 'Intel'/'HDA Intel at 0xf2520000 irq 43'
   Mixer name : 'Intel IbexPeak HDMI'
   Components : 'HDA:14f15069,17aa2156,00100302 HDA:80862804,17aa21b5,00100000'
   Controls : 12
   Simple ctrls : 6
 Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw 6QHT28WW-1.09'
   Mixer name : 'ThinkPad EC 6QHT28WW-1.09'
   Components : ''
   Controls : 1
   Simple ctrls : 1
 Simple mixer control 'Console',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
Date: Tue Apr 5 11:56:28 2011
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=58280e6e-d161-43ea-8593-a89fb7b6851a
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100427.1)
MachineType: LENOVO 5129CTO
 PATH=(custom, user)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-7-generic root=UUID=82571cfb-fdda-4d2f-b708-f8924aa0fe21 ro quiet splash vt.handoff=7
 linux-restricted-modules-2.6.38-7-generic N/A
 linux-backports-modules-2.6.38-7-generic N/A
 linux-firmware 1.49
SourcePackage: linux
UpgradeStatus: Upgraded to natty on 2011-02-24 (39 days ago)
dmi.bios.date: 04/20/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6QET44WW (1.14 )
dmi.board.name: 5129CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6QET44WW(1.14):bd04/20/2010:svnLENOVO:pn5129CTO:pvrThinkPadX201s:rvnLENOVO:rn5129CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 5129CTO
dmi.product.version: ThinkPad X201s
dmi.sys.vendor: LENOVO

Jamie Strandboge (jdstrand) wrote :
description: updated
Changed in thinkfan (Debian):
status: Unknown → New
rejon (rejon) wrote :

So the immediate solution is what?

I chucked this into my /etc/rc.local file before exit 0:

rmmod thinkpad_acpi
modprobe thinkpad_acpi fan_control=1
echo "level 7" > /proc/acpi/ibm/fan
# echo "level disengaged" > /proc/acpi/ibm/fan
# this is being problematic
# echo "level auto" > /proc/acpi/ibm/fan

I ekpt the other settings just in case.

Brad Figg (brad-figg) on 2011-04-07
Changed in linux (Ubuntu):
status: New → Confirmed
Jamie Strandboge (jdstrand) wrote :

Just confirmed in maverick that a) the same test case does not raise the temperature quite as high but b) the fan speed is still not correctly set. In other words, with the fans set to 'auto' in maverick, the fan speed still never rose above ~4500 rpm even though the temperatures were very high (~90C).

Dustin Kirkland  (kirkland) wrote :

Marking critical.

I have hit this bug recently in both Natty and Maverick.

I'm marking critical, as this affects a) server uptime, and b) possibly can cause real-life physical damage.

Changed in linux (Ubuntu):
importance: Undecided → Critical
Changed in linux (Ubuntu Maverick):
status: New → Confirmed
importance: Undecided → Critical
tags: added: kernel-key
Jamie Strandboge (jdstrand) wrote :

I went poking around the BIOS (I also have the most up to date BIOS for my x201s: 1.34) and noticed something called 'Advanced Thermal Management'. It was set to 'Maximum Performance' when on A/C. I changed this to 'Balanced' (which is what is used on battery) and the situation is considerably improved, but not solved. I have gathered more information:

Fan speeds (observed by setting the level manually in /proc/acpi/ibm/fan):
auto: ~4500rpm max (but may be lower depending on temperature)
level 6: ~4500rpm
level 7: ~5300rpm
disengaged: ~6500

CPU speeds:
lowest: 1199 MHz
highest: 2134 MHz

To monitor:
$ watch -n 0.5 'cat /proc/acpi/ibm/thermal ; cat /proc/acpi/ibm/fan | egrep "(speed|level):" ; cat /proc/cpuinfo | grep MHz'

$ watch -n 0.5 'cat /proc/acpi/ibm/thermal ; cat /proc/acpi/ibm/fan | egrep "(speed|level):" ; cat /proc/cpuinfo | grep MHz'
temperatures: 65 0 0 0 0 0 0 0
speed: 4501
level: auto
cpu MHz : 1199.000
cpu MHz : 1199.000
cpu MHz : 1199.000
cpu MHz : 1199.000

Kernel thermal zones: aiui, this controls cpu scaling:
$ cat /sys/class/thermal/thermal_zone0/trip_point_*

When set to 'balanced', the BIOS will scale the CPU back way before 91.5C (at 83C it immediately scales back to 1199 MHz). The trip point appears to not mean anything (except to suggest that things aren't critical until we are at > 91.5).

I turned thinkfan off and set the fan to 'auto' (the default) and I then went about trying to stress the machine:
$ apt-get install stress
$ stress -c 8 -i 8 -m 8 -d 8

With this load, the system was able to manage itself ok. The fan ever only got up to 4500rpm, but when the temperature got to 83C, the cpu scaling kicked in and the temp dropped to 72C. After a bit the CPUs would go back to 2134MHz and the temperature would raise again, then the cpus would be scaled back, and on and on.

So 'stress' was not good enough. What was good enough was doing 3 builds of kde4libs/amd64 concurrently (in an ecryptfs encrypted HOME). After a rather long while (ie all the dependencies are installed, configure is done, the .moc files are generated and the compilation kicks goes for several minutes), the 4500rpm speed of the fans with the CPUs all at their lowest speed is not enough and the temperature very slowly rises.

For now, I am adjusting thinkfan to run at level 6 (ie, the fan speed equivalent of 'auto') starting at 70C and level 7 at 85C and above (ie run the fan at the highest controlled speed (but still higher than 'auto') when the temperature is still rising after the cores are running at their lowest speed). This configuration has not been extensively tested, but I will report back if level 7 is not sufficient and the fans need to go disengaged.

Jamie Strandboge (jdstrand) wrote :

It should be noted that thinkfan is an optional universe package that runs as a daemon and can be used to control the fans based on configurable temperatures. Misconfiguration could lead to hardware damage and I mention it here as a workaround only and am not advocating its use generally. If using thinkfan, please read the documentation fully (I've deliberately not posted my configuration so people are forced to read the docs). In other words, don't blame me if thinkfan breaks your system. :)

Phillip Susi (psusi) wrote :

It looks like thinkpads have a non standard ACPI device that handles the fan control, among other things. That is where /proc/acpi/ibm comes from. It is implemented in the kernel in drivers/platform/x86/thinkpad_acpi.c, and has some comments pointing to:


Andy Whitcroft (apw) wrote :

@Jamie -- ok according to upstream this thinkpad-acpi driver is essentially unchanged, and the fans really should be controlled by the EC in the defualt mode. There is no logical reason to expect this change in behaviour. We are going to have to try and narrow down where this change has come from. Could you test some of the mainline kerenls, specifically including the v2.6.35 and v2.6.38 kernels to see if they are good and bad respectivly, and then could you use a few of the intermediate releases and -rcs to narrow our search. Mainline kernels can be found at the URL below. Please report any testing here:



Changed in linux (Ubuntu Natty):
status: Confirmed → Incomplete
assignee: nobody → Andy Whitcroft (apw)
Joseph Salisbury (jsalisbury) wrote :

I have the same issue on my x201. My system has been crashing randomly during the day when the temp hits 100C.

I created a simple little script to work around the issue. This prevents my system from crashing and prevents damage from overheating. I monitor my temps throughout the day and change the speed as needed. I attached the script in case it might help someone else.

Use the script at your own risk and monitor your temperatures!

The script takes four possible arguments: 6, 7, H and A. The script will change the value in /proc/acpi/ibm/fan as follows:

6 for level 6
7 for level 7
H for level disengaged
A for level auto

The script will also start the watch command Jamie posted as well to monitor cpu speed and temp.

Script is attached with the name cool_cpu.sh

Hope this can help someone else.

Jamie Strandboge (jdstrand) wrote :

@Joseph, you may be interested in the 'thinkfan' package, which does this type of thing for you.

Jamie Strandboge (jdstrand) wrote :

@Andy, as stated, this is not a change in behavior-- maverick had the same problem of not spinning the fan high enough (only 4500rpm) when temperatures were particularly high. The difference between maverick and natty is that maverick tends to run ~8C cooler so you hit the critical 100C shutdown less frequently (but still hit it).

The BIOS/EC should be handling this, and indeed it does adjust the fan speed between 0 and 4500rpm just fine. The problem is that it doesn't spin up the fans to a fast enough speed (they are capable of ~6500rpm) when under very high temperatures. Also, when Advanced Thermal Management in the BIOS is set to 'Maximum Performance' (the apparent default for this machine when on AC) the problem is especially aggravated since frequency scaling doesn't seem to occur. When Advanced Thermal Management is set to 'Balanced' (the default when on battery), cpu frequency scaling does occur, which helps with overheating but there are still cases where the CPUs are at their lowest frequency and the fans at their BIOS/EC maximum speed (ie 4500rpm) where the temperature still goes up and you hit 100C.

I have an up to date BIOS/EC according to the Lenovo website. The 'Maximum Performance' vs 'Balanced' might be as designed, but clearly there is a problem when the lowest cpu frequency and the highest fan rpm in the default install is not enough to keep the machine from hitting 100C. While the fix should probably be with Lenovo, perhaps there is something we could do in the driver when i7s hit 85C we should spin up to level 7 (otoh solution).

Changed in linux (Ubuntu Natty):
status: Incomplete → Confirmed
Changed in linux (Ubuntu Natty):
milestone: none → natty-updates

Same issue with T500. When I switch in BIOS to 'balanced' mode when on AC kernel hangs during early initialization.

James Hunt (jamesodhunt) wrote :

Same problem here with T410. Just before my machine shutdown, temperature was 148C.

Andrew Black (bux23) wrote :

My x201s with i7-CPU shows exactly the same behaviour. If a program hangs and creates a lot of CPU workload the temperature rises and if it reaches 100 degrees Celsius a thermal shutdown occurs. Not very nice.

Btw: I use Kubuntu Natty.

Zaphod (flerche) wrote :

Same isue on R500/ Core2Duo - the workaround seems 2 help ....

Gert van Dijk (gertvdijk) wrote :

This issue is occuring for me since a very long time; using Windows the fans have a much higher speed setting compared to using Linux and the thinkpad-acpi driver. However, since the use of Maverick I experience a lot more automatic shutdowns, triggered by thinkpad-acpi, due to overheating. Before, I was using Karmic and also experienced it sometimes.

When monitoring the temperatures manually and setting a fan speed accordingly the CPU is cooled properly, but thinkpad-acpi never triggers higher CPU fan speeds even when > 95 °C! That is, in my opinion, a bug.

I'm having this issue on my T61p - C2D T9300 w/ Nvidia QuadroFX 570M. Both need quite a lot of cooling, especially when using the docking station (less ventilation, more isolation on the bottom).

That's why I don't think this issue is specific for one Thinkpad model, but occuring as soon as you start using thinkpad-acpi, also in older versions of Ubuntu. And yes, it's a universe piece of software not part of the core of Ubuntu, but this should really be fixed as it might cause hardware failures.

I think running a user space software daemon as a workaround is rather 'dirty'.

More hardware related, but still not justifying the behaviour of thinkpad-acpi:
I noticed there was an awful lot of thermal grease on both the CPU and the GPU for the integrated heatsink/fan in my Thinkpad, I cleaned it, replaced this with a proper amount of thermal grease and temperatures are 10 °C lower since then.

Mathias Hasselmann (hasselmm) wrote :

similar issue for X200. thought it would be dirty fans, but apparently not?

Mikhail Zabaluev (mzabaluev) wrote :

On a T61p, after I set the fan level to full-speed and it is showing (and sounding like) ~6300 rpm, still the CPU temperature cannot be kept from growing beyond 95 ℃ when two processes are busy-looping. I am not using thinkfan.

Mikhail Zabaluev (mzabaluev) wrote :

To note, setting the fan level to 7 results in the screaming speed of ~3200 rpm. Something is fishy with these controls.
I have updated the BIOS to the latest version.

Gert van Dijk (gertvdijk) wrote :

Since yesterday I started to use thinkfan with the patch applied from the Debian bug report. This does the trick for now, but I really would like to see a fix for "level auto" in thinkpad-acpi.

It seems common that level 7 (seems the highest) is indeed only halfway the full speed of the fan on a T61p. This has been the case ever since I got this laptop for Linux (3 years now) and is also described on the Thinkwiki webpage somewhere.
If you're not capable of controlling the temperature even with highest fan speed you should check your hardware; then it's not a Ubuntu/software bug. See also my post above.

Deathflyer (christian1-schmid) wrote :

I experience the same behaviour with my T400 - the system automatically shuts down once it reached 85°C due to the low fan speed.

Ivan Pulleyn (ivan-pulleyn) wrote :

I hit this bug today w/an x201s running Maverick. System shut down in the middle of running a high-CPU analysis job. It was a little frightening at first - I thought my machine had died. I think this issues should be raised in priority for a fix. In the mean time, I'll manually set the fan to disengaged when running jobs.

Shetty (shetty) wrote :

Issue :
Hav this problem while running videos like GoogleIO on several tabs, on chrome or firefox apps (adobe flash player installed), on my dell inspiron laptops: n5030(i3,4GiB), 1525(core2 duo3GiB), & on latitude e5420(i7-2620M, 8GiB), which on prolonged CPU usage(all cores) of over 100% just SHUTDOWN (processes killed).
My old dell inspiron-6400(dual core,4GiB), HP-530(dual core,2GiB), do go high on CPU usage, but get stable (on watch).
The Dell Desktop(Pentium D, 2GiB) works just fine (with other issue - wifi conn suddenly droppd).
All this... while the ancient HP Pavilion(AMD64Athlon) is handling 10.10 well & the ancient dell-celeron(128Mib) runs XUbuntu smoothly.

Resolution :
Waiting for the system to settledown (on startup), then, monitoring the CPU usage, using System-Monitor, & a lil patience has helped most times.

 Running one video and a few regular pages on the browser apps, jets the CPU to over 90~95% , then drops to around 30~40% and stabilized, though opening more links (one or more) shoots the CPU near perfect. At this point, I have been switching to the System-Monitor and just WAIT for the CPU history graph to come down.. It comes back to below 50%. Opening another app, like Eclipse, or Gimp takes the CPU usage to around 65~75% and comes back down to around 40~50%.
 For me, the pain point is tabbed-browsing. While opening more tabs, not scrolling through the pages seems to help get the CPU history graph back to <50%.

Hope the info helps the learned help me out here.

Thomas Hood (jdthood) wrote :

I experienced this problem (sudden shutdown due to overheating) on a ThinkPad X61. I worked around it by manually setting the fan speed higher when performing CPU-intensive tasks (e.g., installing an OS on a guest virtual machine).

Will now install thinkfan which should automate this.

brujonildo (curandero13) wrote :

I also had the temperature-related shutdown problems when running python and c++ colde on a Thinkpad X201 with Ubuntu 10.04. Installed cool_cpu Joseph Salisbury wrote on 2011-04-14 (see comment 9 above). I ran
>> cool_cpu.sh H
The read out from the cpu while at its peak stress while running c++ code I have had so far is:
Every 0.5s: cat /proc/acpi/ibm/thermal ; cat /proc/acpi/ibm... Sat Jul 16 11:24:47 2011

temperatures: 90 0 0 0 0 0 0 0
speed: 6013
level: disengaged
cpu MHz : 2667.000
cpu MHz : 1199.000
cpu MHz : 1199.000
cpu MHz : 1199.000
Running my code with level 7 did not do the trick and the computer quickly shut down.
The room temperature was about 22C and the computer was sitting on a wooden table (faster shut downs due to overheating). I was even able to work other things or run small python or c++ programs while running the code, which was, needless to say, impossible before.
Thank you Joe.

Guillaume Emont (guijemont) wrote :

I can reproduce the issue on a t410s. In auto, the fan speed never goes much above 4000rpm, even though un unengaged it can reach ~6100rpm. This allows the temperature to raise to the security self-shutdown at 128C, e.g. when compiling big projects.

Chad Miller (cmiller) wrote :

Also on x301, gets very hot, but not so hot it shuts down yet. I fear it's damaging my nearby batteries though.

Greg Gorman (gregg-public) wrote :

Any chance to get this into Lucid LTS? Wondering if the patch proposed on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610722 works...

I would like to confirm that the same problem occurs on Ubuntu 10.04 on x201. While compiling a bigger project using make -j4, the temperature increased to 90+C while on auto. After that I forced disengaged mode manually, leading to the increase of fan speed and reduction of temperature.

cometdog (ericctharley) wrote :

I can confirm the problem on Ubuntu 10.10 on a Lenovo W500 with kernel 2.6.35-30-generic-pae-tuxonice (and every other recent kernel I've tried).

Can't boot with BIOS AC setting on Balanced, which would allow frequency scaling to kick in at lower temp to keep things cool.

Temp climbs up to >90C under full CPU load, because fan never goes to "disengaged" mode (~4900 RPM) when set to "auto." If I manually set to disengaged, then temp maxes out at 70C or so.

Alex Roper (alexr-ugcs) wrote :

I did some more testing and have been able to reproduce this under Windows (both reimage from their restore partition and fully upgraded); I think this may be a hardware/BIOS problem. I sent mine in for repair today.

Greg Gorman (gregg-public) wrote :

Any chance the fix in debbugs #610722 works? This seems to be a very serious hardware damage issue and nothing seems to have progressed?? If that fix works, can this be pushed out asap?

Noel J. Bergman (noeljb) wrote :

I have the same experiences as commetdog in comment #30 and Gert van Dijk in comment #20

The only way I can actually get the CPU cool is by running the fan at full-speed (~6000RPM). The other fan speeds only slow the heat increase.

I've patched thinkfan to allow level 127 (full-speed), and (thus far) added the following to thinkfan.conf:

(7, 54, 85)
(127, 75, 32767)

This means that once we hit 85C, the fan goes to full speed, and does not come back down until we're at or below 75C. And, as a general rule, those are the only two rules that get exercised by my system (T61p).

summary: - Thinkpad x201* overheats due to slow fans when on 'auto'
+ Thinkpads overheat due to slow fans when on 'auto'

From the Debian bug report:
"I've just put thinkfan 0.7.3 on sf.net, which (I hope) will eliminate all problems with using 127 or -2147483648 as a fan level."

Is it possible to upload 0.7.3 for oneiric or backport the fix upstream to 0.7.1?

Gert van Dijk (gertvdijk) wrote :

While this is considered a critical issue, the workaround (thinkfan) is affected by another bug and it still isn't fixed after almost six months... I have put a how-to online on how to patch&build&configure thinkfan for affected users not comfortable in building packages.
Hope this helps.

Changed in thinkfan (Debian):
status: New → Fix Released
Changed in linux (Ubuntu Maverick):
assignee: nobody → Abhishek kumar singh (abhishekkumarsingh-cse)
status: Confirmed → In Progress
Francisco Villar (villarf) wrote :

Bug confirmed on 11.10 Oneiric with Thinkpad t60.

Manav Gupta (manavg) wrote :

I sure wish a fix is released for this, since my laptop has become practically unusable since I upgraded to Natty.

$ uname -a
Linux mg-ThinkPad-T410 2.6.38-11-generic-pae #50-Ubuntu SMP Mon Sep 12 22:21:04 UTC 2011 i686 i686 i386 GNU/Linux

$ top
top - 17:28:33 up 8 min, 2 users, load average: 0.19, 0.44, 0.34
Tasks: 199 total, 1 running, 197 sleeping, 0 stopped, 1 zombie

$ sensors
Adapter: Virtual device
temp1: +80.0°C (crit = +100.0°C)

Adapter: ISA adapter
Core 0: +74.0°C (high = +95.0°C, crit = +105.0°C)

Adapter: ISA adapter
Core 2: +74.0°C (high = +95.0°C, crit = +105.0°C)

Adapter: ISA adapter
fan1: 7312 RPM
temp1: +80.0°C

The BIOS setting is "Balanced" when the laptop is on AC Power.

$ sudo powertop
Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 0.0%) 2.54 Ghz 6.3%
polling 4.0ms ( 0.2%) 2.27 Ghz 0.2%
C1 mwait 0.1ms ( 0.3%) 1.60 Ghz 0.2%
C2 mwait 1.5ms (30.5%) 1333 Mhz 0.3%
C3 mwait 1.8ms (86.3%) 1199 Mhz 92.9%

Wakeups-from-idle per second : 721.6 interval: 5.0s
no ACPI power usage estimate available

Top causes for wakeups:
  53.3% (413.0) PS/2 keyboard/mouse/touchpad interrupt
  14.1% (109.2) plugin-containe
   8.7% ( 67.8) [mmc0, hda_intel, nvidia] <interrupt>
   3.5% ( 26.8) [iwlagn] <interrupt>

Personally, I think the nvidia drivers also have something to contribute to heat since the temperature skyrockets as soon as I watch a video (flash or otherwise)...

Guys, I have had same problems with all versions of Ubuntu (from 10.04 till 11.10). Used thinkfan to control and put in disengaged mode, the only way to cool things.

Funny end of the story, turned out to be the a dirty cooling unit. All thinkpads has quite good dissipating units, but they tend to be clogged extremely easily. Moreover, some dust get into my fan and was vibrating, so I disassembled entire dissipating block, cleaned tons of dust that was stuck in the dissipator, properly lubricated entire fan unit with some WD40 (circuit friendly), and the result is incredible. I live in the tropics and sometimes I use my T400 without AC. When doing normal activity, fan always throttle normally as it should do. If I use max performance, it will go to the top admitted by auto (which is never same as disengaged in thinkpads) and temperature will slowly increase and stay steady at no more than 70C (GPU too) even if room temp is nearly 30C.

Thinkpad fan is purely controlled by the BIOS. You can install all sort of utilities to manually control the speed, but nothing beats BIOS settings, that are working properly with a clean unit.

If anybody has the problem with a perfectly clean unit, then please report it here.

Forgot to mention: with stock ATI drivers (my PC has HD Radeon 3400), the GPU always stays above 60C even when resting, and CPU get some side heat from the GPU. But even on that configuration, the CPU is never going above 70C, because performance are less in 3D, so GPU always stay more or less the same. With fglrx driver, GPU always stay around 45~48C at rest, triggering the fan to throttle around the second-to-highest level, with high room temps.

Diogo Matsubara (matsubara) wrote :

I'm having the same issue with Oneiric in a Thinkpad x61. It usually shuts down when I'm watching movies. I did the workaround mentioned in the description (set fan level to disengaged) and could watch the whole movie with no shutdown. Fan level without level disengaged was ~4000 rpm and with disengaged enabled ~7000 rpm.

tags: added: kernel-da-key
summary: - Thinkpads overheat due to slow fans when on 'auto'
+ ThinkPads overheat due to slow fans when on 'auto'
Sam Darraj (samo12156) on 2012-01-17
Changed in linux (Ubuntu):
status: Confirmed → Invalid
Kartoch (kartoch) on 2012-01-17
Changed in linux (Ubuntu):
status: Invalid → Confirmed
Changed in linux (Ubuntu Precise):
status: Confirmed → Triaged
tags: added: precise
Changed in linux (Ubuntu Precise):
milestone: natty-updates → none
tags: removed: kernel-key precise
tags: added: kernel-key
eric fortin (nitrof22) on 2012-03-09
Changed in linux (Ubuntu Maverick):
status: In Progress → Fix Released
Changed in linux (Ubuntu Natty):
status: Confirmed → Fix Released
Changed in linux (Ubuntu Precise):
status: Triaged → Fix Released
Changed in linux (Ubuntu Maverick):
status: Fix Released → In Progress
Changed in linux (Ubuntu Natty):
status: Fix Released → Confirmed
Changed in linux (Ubuntu Precise):
status: Fix Released → Triaged
tags: added: rls-mgr-p-tracking
JC Hulce (soaringsky) on 2012-05-03
Changed in linux (Ubuntu Maverick):
status: In Progress → Invalid
Kartoch (kartoch) on 2012-05-27
no longer affects: linux
tags: removed: kernel-key
Changed in linux (Ubuntu Precise):
status: Triaged → Confirmed
Simon Wenner (nowic) on 2012-07-05
security vulnerability: no → yes
security vulnerability: yes → no
peggyfounds (pfounds) on 2012-07-11
Changed in linux (Ubuntu Precise):
status: Confirmed → Fix Committed
Changed in linux (Ubuntu Natty):
status: Confirmed → Fix Released
Changed in linux (Ubuntu):
status: Triaged → Fix Committed
Changed in linux (Ubuntu Precise):
status: Fix Committed → Fix Released
Changed in linux (Ubuntu):
status: Fix Committed → Fix Released
Phillip Susi (psusi) on 2012-07-11
Changed in linux (Ubuntu Precise):
status: Fix Released → Confirmed
Changed in linux (Ubuntu Natty):
status: Fix Released → Confirmed
Changed in linux (Ubuntu):
status: Fix Released → Triaged
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in linux (Ubuntu):
status: Confirmed → Fix Committed
Kartoch (kartoch) on 2012-10-22
Changed in linux (Ubuntu):
status: Fix Committed → Confirmed
Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
68 comments hidden view all 148 comments
Joseph Salisbury (jsalisbury) wrote :

@Jamin W. Collins,

Only the Natty series should have been marked as "Wont Fix".

Changed in linux (Ubuntu):
status: Won't Fix → Confirmed
Changed in linux (Ubuntu Natty):
status: Confirmed → Won't Fix
Changed in linux (Ubuntu Maverick):
status: Invalid → Won't Fix
Alexander List (alexlist) wrote :

I am still experiencing this problem on my Thinkpad X201 using 12.10 x86_64.

[ 11.835859] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[ 11.835861] thinkpad_acpi: http://ibm-acpi.sf.net/
[ 11.835862] thinkpad_acpi: ThinkPad BIOS 6QET69WW (1.39 ), EC 6QHT33WW-1.14
[ 11.835864] thinkpad_acpi: Lenovo ThinkPad X201, model 3626A14
[ 11.840344] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[ 11.842060] thinkpad_acpi: radio switch found; radios are enabled
[ 11.842896] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode
[ 11.842912] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver

Maybe this dmesg snippet gives you some hints:

[ 9.618507] intel ips 0000:00:1f.6: CPU TDP doesn't match expected value (found 25, expected 29)
[ 9.619390] tpm_tis 00:0b: TPM is disabled/deactivated (0x6)
[ 9.620441] intel ips 0000:00:1f.6: IPS driver initialized, MCP temp limit 90

Anders Hall (kallebolle) wrote :

Im still experiencing this bug. Bug related to Alexander info, appears to be the same or very similar bug to this one (affects many vendors) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/636045

Confirmed on thinkpad T61. For me this bug is actually new! I experience it only since an upgrade from Ubuntu 12.04 to 12.10 with kernel v3.5. Before I didn't have it.

Myriam Schweingruber (myriam) wrote :

Confirmed (again) on Thinkpad X220. It would really be nice if not every newer kernel I install overwrites my thinkfan settings, this is the 3rd time this happens, now on Kernel 3.5.0-20, 12.10. Really very annoying.

Kartoch (kartoch) wrote :

I've put a wiki page on thinkwiki about this problem:


Please complete, add your machine and test every solution before reporting.

If you cannot edit the page, please send me your comments here.

Phoenix (phoenix-dominion) wrote :

I have a T410 and Ubuntu 12.10. All Updates applied.

I did the manual kernel module load and set the fan to disengaged.

With the script here provided I see:

Every 0.5s: cat /proc/acpi/ibm/thermal ; cat /proc/... Wed Jan 16 11:09:39 2013

temperatures: 95 0 0 0 0 0 0 0
speed: 4951
level: disengaged
cpu MHz : 2667.000
cpu MHz : 2667.000
cpu MHz : 2399.000
cpu MHz : 1999.000

Top was 97°C

Fan never goes higher than the value shown... ~4950rpm.

Phoenix (phoenix-dominion) wrote :

Just tried thinkfan with its default settings

The level goes up to 7... that is around 4,5k rpm.

Eventually the Temperatre goes above 100°C - last I saw was 101°C and system shuts down.

ii thinkfan 0.8.1-1 amd64 simple and lightweight fan contro

Phoenix (phoenix-dominion) wrote :

I did another run without thinkfan and manually set the speed to "disengaged"

Top was 100°C and 4972rpm.

I watched the output of the script closely and I notived, that around 95°C the CPU throtteling kicks in and lowers the Speed from 2,6GHz to 1,2GHz. At atound 85°C it goes again to 2,6GHz. So the CPU goes faster and slower as temperature rises and falls. I guess I can kill my system faster by using GPU in addition (by just browsing the web...)

I assume that eventually at 95°C the thremal throtteling of the CPU speed is a tick to late and the fans dont respond in addition not quite as swiftly to deliver those 4970tpm that causes the >100°C. Which leads to the emergency shutdown.

From my point of view, the system is in constant thermal edge as it has to lower its speed due to overheating. I would love to see the system not exceed the temperature which would lead to speed throtteling. Which leads to the question, can a faster fan speed meet such a desired temperature and the ultimate question, why does the fan not go faster?

Phoenix (phoenix-dominion) wrote :

As of now, to make this clear, NONE of the provided solutions work. So I can't use my system for something fancy like converting a 30MB WMV with h264encoder.

Phoenix (phoenix-dominion) wrote :

So to get my job done, I capped the max cpu scaling...

It's a 2.6GHz CPU, So I went down to 2.4GHz as maximum. But left anything else to they way it is by default. That still leads to a temperature of 95°C but way slower so when the cpu scaling then kicks in the cpus are cooler way faster as they are not at 2.6GHz when speed gets reduced... but thoses 95°C get hit pretty often, so I lowered it to 2,26GHz and it still hits 95°C... but not that fast.... so I lowered it to 2,13GHz

temperatures: 94 0 0 0 0 0 0 0
speed: 4518
level: auto
cpu MHz : 1199.000
cpu MHz : 1199.000
cpu MHz : 2133.000
cpu MHz : 2133.000

That way the system operates stable at 93-94°C

Phoenix (phoenix-dominion) wrote :

Just another run of my task at hand which looks cpuwise like this:

temperatures: 94 0 0 0 0 0 0 0
speed: 4544
level: auto
cpu MHz : 2133.000
cpu MHz : 2133.000
cpu MHz : 2133.000
cpu MHz : 2133.000

I rather have my CPUs at 21/26 (80%) of their power than having them to cool down to 85°C at 1,2GHz until they get up to 2,6GHz just to see them overheat at fall back to 1,2GHz... which in the end leads to about an average of 2,1GHz ;)... but eventually shuts the system :(

Hash: SHA1

On 1/16/2013 5:54 AM, Phoenix wrote:
>> From my point of view, the system is in constant thermal edge as
>> it has
> to lower its speed due to overheating. I would love to see the
> system not exceed the temperature which would lead to speed
> throtteling. Which leads to the question, can a faster fan speed
> meet such a desired temperature and the ultimate question, why does
> the fan not go faster?

You would have to ask IBM why they keep designing broken laptops.

Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


I have working fan control using this page to get fan control working in the first place:

and once I could use 'full-speed' to set the fan speed I moved on to thinkfan.

Using thinkfan I just have the max heat level set at "level disengaged" (in quotes), and everything is working perfectly. My x201 sounds like a jet engine exactly as I want it to during encodes! :)

Rainer (r-e-l) wrote :

I have the same problem on my TP R60.

Adding (127, 66, 32767) at the end to /etc/thinkfan.conf lead me to have the fan running at disengaed by auto. This results in seltem having temparute over 85°C.

Further I found, that the VID is to high by default. If I set the governer to userspace 1.833GHz and reduce the VID using
wrmsr -p0 [1] 0x0199 0x0b20
The temparature goes not over 65°C.

The governer "ondemand" switches the MSR 0x199 between 0x0613, 0x081c, and 0x0b28. This 0x0b28 should be reduced to 0x0b20 and every thing would fine.

Damien Challet (dchallet) wrote :

As a workaround, I use

sudo pm-powersave

which decreases the temperature from more than 100C to about 92C when running computations on two+two cores (t410 here).

Damien Challet (dchallet) wrote :

Note also that I run pm-powersave every 60s, otherwise, the pm-powersave settings are lost and temperatures climb again.

Damien Challet (dchallet) wrote :

Sorry, forgot to add true at the end of the command line: I use
 watch -n60 sudo pm-powersave true

Changed in linux (Ubuntu):
status: Confirmed → New
Changed in linux (Ubuntu Precise):
status: Confirmed → New
Changed in linux (Ubuntu):
status: New → Confirmed
status: Confirmed → New

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Changed in linux (Ubuntu Precise):
status: New → Confirmed

For me at least it turned out to be a hardware problem. After getting the fan replaced I'm not experiencing this problem at all.

tnhh (tnhh) wrote :

Updating the BIOS on my X201s seems to have reduced the system temperature. Not sure why since the changelog for 1.40-1.15 only says "Embedded Controller update will modify battery charge algorithms to balance battery charging and lifespan."


1 comments hidden view all 148 comments
Robotron (robotron) wrote :

Vacuum cleaner fixed the problem for me. My Thinkpad x201i was reaching 100C temperature regularly after only a few minutes of full load. I removed keyboard and cleaned the cpu cooler with a vacuum cleaner. Maybe it could be done by cleaning the cpu cooler venhole only from the outside.

Now I never reach temperatures over 85C even with closed lid in the docking station and after prolonged time on full load. Standard cpu temperature is ~ 60C.

Daniel (daniel-admin-box) wrote :

+1 on "Vacuum cleaner fix"!
Thinkfan still has to "disengage" for high loads, but during summer it got to the point where the T410 would regularly throttle the CPU down to 1.2GHz cause of to much heat. That doesn't happen after vacuuming anymore. System can run for hours at full speed (with fan disengaged).

Jamie Strandboge, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:

where VERSION-NUMBER is the version number of the kernel you tested. For example:

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:

If the mainline kernel does not fix this bug, please add the following tags:

As well, please remove the tag:

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

summary: - ThinkPads overheat due to slow fans when on 'auto'
+ [Lenovo Thinkpad x201s] Overheat due to slow fans when on 'auto'
tags: added: bios-outdated-1.15
Changed in linux (Ubuntu):
status: Confirmed → Incomplete

I can confirm this is still happening on Ubuntu 13.04 x64 on my Thinkpad R500. The thinkfan improves, but doesn't solve the issue, so does cleaning the inside from dust.

I will try to install the new ubuntu release.


Tristan Nakagawa, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices
Ubuntu Community: https://wiki.ubuntu.com/ReportingBugs

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report would delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Alexander List (alexlist) wrote :

I have been working since my first comment on this bug using the fan speed set to max, with the result that my fan is no de facto dead and I had to get a replacement heatsink assembly ...

I will happily test using the instructions for Jamie above, so we can get this fixed before Saucy release ...

drukman (drukman2000) wrote :

Had this issue with x201:
-sudden shut down
-temp going to 95c
-language stickers piling off cause of the warm -))

Took a huge vacuum cleaner & attached it to the upper left side where the fan resides
Since than temp never went over 55c even when the unit is under heavy load.

All the best - Drukman.

Jean Jordaan (jean-jordaan) wrote :

Thinkpad X201i, was running fine for a couple of years under 10.10, upgraded to 12.04, now the machine is overheating and shutting down regularly.

Overheating experienced while running test suites or while watching video, Skype video calls, or Firefox Flash plugin activity.

15:20 jean@klippie:~$ uname -a
Linux klippie 3.8.0-33-generic #48~precise1-Ubuntu SMP Thu Oct 24 16:28:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
15:22 jean@klippie:~$ dmesg | grep ASPM
[ 0.230873] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 0.366429] pci0000:ff: ACPI _OSC support notification failed, disabling PCIe ASPM
[ 0.380548] ACPI _OSC control for PCIe not granted, disabling ASPM

Alexander List / Jean Jordan, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report would delay your problem being addressed as quickly as possible.

No need exists to comment here at this time. After reading the above documentation in it's entirety, if you have further questions or comments, you are welcome to redirect them to the appropriate mailing list or forum via http://www.ubuntu.com/support/community/mailinglists , or you may contact me directly.

Thank you for your understanding.

Jean Jordaan (jean-jordaan) wrote :

@penalvch, mine is not a new report, just a data point on this issue ongoing since 2011-04-06, and before that on Bug #370173 since 2009-05-01, still unresolved.

I suspect opening a new (duplicate) bug will not help matters. That said `apport-collect` wouldn't let me add info to this report, so I added my info at https://bugs.launchpad.net/ubuntu/+source/linux-lts-raring/+bug/1254576

To trigger this issue I installed Ubuntu 12.04, updated to the present.

Mark (mark-wege) wrote :

For me the issue is fixed in Saucy, by doing a few things. I am not sure if it is the combination or one of them did the trick:
- Installing: intel-microcode -> Update of the CPU-Firmware
- running thinfan with the attached configuration (note: you must look for more detailed installation instructions on the net, the sensor settings are for a X201 only. You need to adjust them for other machines)
- installing i965-va-driver
- I also have updated my Bios to the latest version. But this was a while ago and did not help. But it may contribute to it.

Before that I had an average temperature of 80 and quite often sudden peaks leading to 100 and a shutdown. Now I have a permanent temperature below 60 and only a few peeks above. What I am sure of is that it did not help to have thinkfan installed, did not help alone.

I have to note that I am running a x201 and have an SSD. Switching from a hardrive to SSD did not change a thing. So I assume this "solution" works also with a harddrive.

Before having this solution it helped to remove the battery to prevent the overheating from happening.

Anders (eddiedog988) on 2014-03-13
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Mark (mark-wege) wrote :

Incomplete is a nice decription for "no one is caring.". Fact is that in (K)Ubuntu's default installation this bug appears and is very annoying. For me it is also a fact, that the problem can be solved, by the procedure I have described. Unfortunately I can not tell which one did the fix. But it means the default installation for Thinkpads can be fixed.

Mark, so your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:

Phillip Susi (psusi) wrote :

It isn't don't care so much as it is that the bug lies in the laptop's bios, not linux.

> It isn't don't care so much as it is that the bug lies in the laptop's bios, not linux.

I'm not competent to say whether it's in the bios, but for the sake of discussion I can accept that. But it's noticeable that some of the reports here are indicating that things were better in the past, then got worse with later revisions of Ubuntu. Doesn't that indicate that, regardless of "where the bug lies", there is the possibility of working around it outside the bios? Phillip, I don't feel you should dismiss Mark so hastily.

That all said, clearly it's a problem that will be difficult for developers to reproduce, and which factors such as exact hardware revision, bios revision, thickness of fluff in the fan duct (!) and much else will all influence. Good accurate reporting will be needed.

Phillip Susi (psusi) wrote :

As others have noted, the workaround is to set the fan to disengaged mode so that it runs at full speed. As for it previously being worse; in some cases it sounds like there may have been less dust in the fan at an earlier time, and in others, various changes over time may have caused the cpu to work harder and generate more heat. The bios is supposed to respond to more heat by ramping up the fan speed, but reports indicate this is broken and the bios won't go over 4000 rpm unless you override it with the disengaged state.

Mark (mark-wege) wrote :

@Philipp: With my "solution" which works for, there is no need to run the fan on disengaged. At the moment e.g. the fan is not running at all and I am happy with 44° Celsius which rather low. But when I am stressing the system more, the temperature hardly ever rises above 60° Celsius. Then the fan is running, but definitely not on full speed. Before that I was seldomly below 80° and I often had the system quickly rising towards 100°. Unfortunately I can not say what really did the trick. But I am quite sure the Bios can only contributed with a small factor. I updated the Bios months before the other things and there was only a little improvement. I rather suspect that installing the installing "i965-va-driver" and a newer kernel did something. I suspect this, because the overheating mostly only happened when I was doing things which stressed the gpu (watching movies, encoding video). At least in my installation the "i965-va-driver" was never installed by default.

Phillip Susi (psusi) wrote :

That driver allows using the GPU for video encoding/decoding, which reduces the load on the cpu during those activities, and thus, the heat it generates. A heavy load will still cause it to overheat because the real bug is that the bios does not speed up the fan correctly when it does get too hot.

tags: removed: kernel-da-key
saioa (sairis37) on 2014-04-07
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
status: Confirmed → Fix Committed
Changed in linux (Ubuntu Precise):
status: Confirmed → Incomplete
status: Incomplete → Confirmed
status: Confirmed → Fix Committed
status: Fix Committed → Fix Released
Changed in linux (Ubuntu):
status: Fix Committed → Incomplete
Changed in linux (Ubuntu Precise):
status: Fix Released → Confirmed
Displaying first 40 and last 40 comments. View all 148 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.