thinkpad-acpi X200 Thinkpad fan fails to spin down .

[Andrew Mason]

The fan on my thinkpad acpi begins in 'level 1' mode on boot or shortly after.

root@portland:~/Kernel# cat /proc/acpi/ibm/fan
status: enabled
speed: 1875
level: 1
commands: level <level> (<level> is 0-7, auto, disengaged, full-speed)
commands: enable, disable
commands: watchdog <timeout> (<timeout> is 0 (off), 1-120 (seconds))

After some usage it climbs to

root@portland:~/Kernel# cat /proc/acpi/ibm/fan
status: enabled
speed: 3387
level: auto

However it fails to drop back to its normal speed once the temperature has dropped back to it's pre-boot temperature.

root@portland:~/Kernel# acpi -V
     Battery 0: Discharging, 58%, 04:16:44 remaining
     Battery 0: design capacity 84240 mAh, last full capacity 84390 mAh = 100%
  AC Adapter 0: off-line
     Thermal 0: ok, 33.0 degrees C
     Thermal 1: ok, 36.0 degrees C
     Cooling 0: LCD 9 of 15
     Cooling 1: Processor 0 of 10
     Cooling 2: Processor 0 of 10

Although the fan is reasonably quiet I assume it would use more battery to spin the fan at the higher speed.

root@portland:~/Kernel# cat /proc/acpi/ibm/thermal
temperatures: 35 44 -128 35 31 -128 30 -128 40 38 -128 -128 -128 -128 -128 -128

The thinkpad is also pretty thin and doesn't feel at all hot anywhere on any surface.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=UUID=e9f54ed0-3930-4863-a768-ebebe968bfc4
MachineType: LENOVO 7454A13
Package: linux-image-2.6.30-020630rc7-generic 2.6.30-020630rc7
ProcCmdLine: root=UUID=f808f408-9cd9-44d2-8e4d-fda7e2f4e012 ro quiet splash
ProcEnviron:
 LANGUAGE=
 PATH=(custom, no user)
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Error: [Errno 2] No such file or directory: '/proc/version_signature'
SourcePackage: linux
UnreportableReason: This is not a genuine Ubuntu package

[Andrew Mason (slackmase2)]

This was done with the latest mainline kernel, since you always ask for this to be tested anyway. The previous kernels also have this behaviour.

root@portland:~/Kernel# uname -a
Linux portland 2.6.30-020630rc7-generic #020630rc7 SMP Sun May 24 01:38:23 UTC 2009 i686 GNU/Linux

[gdi2k (gdi2k)]

Same issue here, I have an x200 too. I'm having to use ThinkPad Fan Control to work around this, which does work.

[Ali Sabil (asabil)]

Same issue here.

[Sam (sam-bowling)]

There isn't an issue with the driver, it is actually functional. The problem is that the levels defined are drastically different in speed as seen here:
root@thinkpad:/sys/bus/platform/drivers/thinkpad_hwmon# echo 'level 4' > /proc/acpi/ibm/fan
root@thinkpad:/sys/bus/platform/drivers/thinkpad_hwmon# cat /proc/acpi/ibm/fanstatus: enabled
speed: 3928
level: 4
commands: level <level> (<level> is 0-7, auto, disengaged, full-speed)
commands: enable, disable
commands: watchdog <timeout> (<timeout> is 0 (off), 1-120 (seconds))
root@thinkpad:/sys/bus/platform/drivers/thinkpad_hwmon# echo 'level 3' > /proc/acpi/ibm/fan
root@thinkpad:/sys/bus/platform/drivers/thinkpad_hwmon# cat /proc/acpi/ibm/fanstatus: enabled
speed: 3829
level: 3
commands: level <level> (<level> is 0-7, auto, disengaged, full-speed)
commands: enable, disable
commands: watchdog <timeout> (<timeout> is 0 (off), 1-120 (seconds))
root@thinkpad:/sys/bus/platform/drivers/thinkpad_hwmon# echo 'level 2' > /proc/acpi/ibm/fan
root@thinkpad:/sys/bus/platform/drivers/thinkpad_hwmon# cat /proc/acpi/ibm/fanstatus: enabled
speed: 3371
level: 2
commands: level <level> (<level> is 0-7, auto, disengaged, full-speed)
commands: enable, disable
commands: watchdog <timeout> (<timeout> is 0 (off), 1-120 (seconds))
root@thinkpad:/sys/bus/platform/drivers/thinkpad_hwmon# echo 'level 1' > /proc/acpi/ibm/fan
root@thinkpad:/sys/bus/platform/drivers/thinkpad_hwmon# cat /proc/acpi/ibm/fanstatus: enabled
speed: 1739
level: 1
commands: level <level> (<level> is 0-7, auto, disengaged, full-speed)
commands: enable, disable
commands: watchdog <timeout> (<timeout> is 0 (off), 1-120 (seconds))
root@thinkpad:/sys/bus/platform/drivers/thinkpad_hwmon#

Perhaps a change in the detection of levels would help but I am unsure of how the levels are defined by the driver.

[Sam (sam-bowling)]

I also used the windows program http://sourceforge.net/projects/tp4xfancontrol/ to monitor fan speed while using windows 7. At idle the fan runs at around 3667 rpm while docked. While plugged in via AC or unplugged and not docked at idle it is at around 2280 rpm. I think either thinkpad_acpi thinks the laptop is always docked or levels 2-4 need worked on to have proper speeds.

When testing the levels I was using 2.6.28-15-generic with the latest thinkpad_acpi patch applied.

[Andrew M (andrew-miniatureworldmaker)]

Well apparently on Vista ( i don't have vista so can't test this ) with the thinkpad drivers the fan doesn't spin up unless the machine gets hot enough. Henrique doesn't really like userspace fan controls from what I understand, however they are useful for testing.

I have confirmed that at least on a new Linux kernel you can pretty much go about your business without the fan on at all (at low work loads) for about half and hour before the system heats up to around 40-42 degrees c. After which if you turn on the fan at around 1739 (level 1) it can pretty much cool the system back to 33-35 degrees in a few minutes.

When automatically controlled the fan never seems to drop back from 3371 after it has kicked in initially. I can only imagine that running the fan at this pace leads to reduced battery life.

[Jeremy Foshee (jeremyfoshee)]

Hi Andrew,

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? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

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

apport-collect -p linux 380303

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Andrew M (andrew-miniatureworldmaker)]

Hi Jeremy,
I've just updated to Lucid and I'm using the Linux portland 2.6.34-020634rc1-generic kernel and will let you know if the issue still occurs. It was still present in 2.6.33 mainline and is still an issue in the .32 kernel shipping in lucid.

Also i tried to run apport as you requested.

am@portland:~$ apport-collect -p linux 380303
Usage: apport-kde <report number>

apport-kde: error: no such option: -p

So i tried this:

am@portland:~$ apport-collect 380303
Error connecting to Launchpad: [Errno 1] Operation not permitted: '/home/am/.launchpadlib'
You can reset the credentials by removing the file "/home/am/.cache/apport/launchpad.credentials"

I tried removing the .cache/apport directory but that doesn't seem to help. Any ideas how I can get the info you require. Using Kubuntu.

[nosolosw (nosolosw)]

Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: nes 1933 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf2620000 irq 17'
   Mixer name : 'Conexant CX20561 (Hermosa)'
   Components : 'HDA:14f15051,17aa20ff,00100000'
   Controls : 14
   Simple ctrls : 7
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=84e5f218-78b7-4f4e-a269-89b383d322e1
MachineType: LENOVO 74558GG
Package: linux (not installed)
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.31-20-generic root=/dev/mapper/vg-ubuntu ro splash quiet
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-20.57-generic
RelatedPackageVersions:
 linux-backports-modules-2.6.31-20-generic N/A
 linux-firmware 1.26
Uname: Linux 2.6.31-20-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 11/09/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 7XET61WW (3.11 )
dmi.board.name: 74558GG
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:bvr7XET61WW(3.11):bd11/09/2009:svnLENOVO:pn74558GG:pvrThinkPadX200:rvnLENOVO:rn74558GG:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 74558GG
dmi.product.version: ThinkPad X200
dmi.sys.vendor: LENOVO

[nosolosw (nosolosw)]

I have tried:

  apport-collect -p linux 380303

and it seems to work (as a lot of files were uploaded to this bug). Sorry for the noise, but I though the app would upload them in a single patch.

Hope that be useful.

[Jeremy Foshee (jeremyfoshee)]

amaneiro / Andrew M,
    There is currently a known issue with apport. We are working to resolve it, but it seems that a recent update caused some breakage. I'll let you know when it hits updates.

Thanks!

~JFo

[Andrew M (andrew-miniatureworldmaker)]

Ok no worries, will try again tonight.

[Andrew M (andrew-miniatureworldmaker)]

Ok apport seems to think this bug is closed when afaik it's not. Also i am currently running lucid however there are no more .34 kernels for lucid except for one which oop's. Going to give up on this for now and aim for Luicid+1. It's been there since hardy, i guess i can wait another release.

[Nathan Brooks (nbbrooks)]

Would having data from another laptop/version help get this fix back in the works? I am running 9.10 and the fan is always running (although not at full speed) and the laptop is very cool. I haven't tested what kind of hit the battery life is taking compared to running in Windows, but it can't be pretty...

[Leonardo Horovitz (lenilucho)]

it has been confirmed by several users.

[Leonardo Horovitz (lenilucho)]

I have 2 different models of x200 to work with. Both have the same problem. How can I help to solve it?

[Andrew M (andrew-miniatureworldmaker)]

I keep getting this with lucid.

You are not the reporter or subscriber of this problem report, or the report is a duplicate or already closed

Please help, i really would like to help to get this bug fixed but I am having a hard time getting the information you require:

[Andrew M (andrew-miniatureworldmaker)]

 Can confirm with Linux portland 2.6.34-020634-generic #020634 SMP Mon May 17 20:34:55 UTC 2010 i686 GNU/Linux

[iponeverything (cookema)]

I am seeing this issue on an x200s with 9.10 32 bit and a x200 with 10.04 64 bit

Fan seems to stays at around 3800 RPM regardless of temperature. Idle my cpu is 33 C and a kernel build with -j 4 will push it over 61 C with no change in fan speed. I can use "echo level x > /proc/acpi/ibm/fan" to adjust the fan speed manually -- but after a couple of minutes -- it reverts to auto on its own. I don't have windows on either of machines, so I don't know what the behavior of Embedded Controller is under windows.

x200 with 10.04:
Linux mac 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 UTC 2010 x86_64 GNU/Linux

running thinkfan, I can see that it is using the second value in /proc/acpi/ibm/thermal which is HDAPS according to http://www.vminko.org/gentoo_on_x200#acpi. thinkpad_acpi.c appears to show that it has not been modified since 2007.

from thinkpad_acpi.c

/*
 * Changelog:
 * 2007-10-20 changelog trimmed down

Though I am assuming that when level=auto, fan speed is handled though the Embedded Controller and has little interaction with thinkpad_acpi -- but assuming ECP works correctly under windows, the problem would seem to point to issue with the kernel's interaction with ECP.

Has anyone updated the ECP to 1.06 (7XHT24WW) on the x200 to see if it fixes the fan issue?

Anyway, just though I would add my 2 cents.

[iponeverything (cookema)]

Just checked and realized that I am at 1.06 for the ECP.

[Georg Sauthoff (g-sauthoff)]

Well, using a Thinkpad x200 I am observing the same problem (when idle again fan does not reduce its speed).

Unlike in the comments, I was not hit by this issue until now. It worked the last two versions before lucid fine. And under Lucid there was not a problem until the last apt-get upgrade && reboot.

Now I am running:

$ uname -a
Linux lenovo 2.6.32-24-generic
$ cat /etc/issue
Ubuntu 10.04.1 LTS

I remember that in the past I observed this behavior just a very few times after a fresh boot, but it went away after the first suspend/resume cycle (via pm-suspend).

[Georg Sauthoff (g-sauthoff)]

Well, to update: it went away again for me after a dock/un-dock cycle (at a docking station).

[Scott Ritchie (scottritchie)]

This issue needs to be reported upstream -- I was unable to find a comparable bug in the kernel bug tracker.

Please:
1) Confirm issue still exists in 10.10 (probably does)
2) Try the mainline kernel in Maverick https://wiki.ubuntu.com/Kernel/MainlineBuilds
3) Report the result here
4) If it's still an issue in the mainline kernel, also report it at http://bugzilla.kernel.org/ and post the link here

Sorry you didn't receive these instructions earlier. Thank you everyone for your patience

[Alex Thompson (alexofdoom)]

I've finally got around to upgrading my laptop (X301) to 10.10 and after a bit of testing the issue seems to be resolved.

The fan now spins down to zero with no cpu activity (and if the ambient temperature allows it).

[Michael Eklund (tinfoilhat)]

Right. I've observed this behaviour as well using my x200s with 64-bit lucid. Fan speed goes to around 3700 rpm and doesn't come back down when the CPU goes back to idling.

Then I read the above post and updated to 10.10 - but no change whatsoever. Got frustrated and reinstalled 10.04, and experimented with everything I could think to experiment with... not much luck though. Since it was mentioned above, I decided to check my embedded controller firmware, but yeah, 1.06.

Then I got patient and installed the gnome sensor applet... and watched and watched. My fan speed does actually go down, but it takes quite awhile of idling. I assume we have been assuming that the fan would basically follow the CPU temps, yeah? I'm thinking the problem rather follows the Mini-PCI temps. The wifi card seems to like to settle somewhere over 50 with traffic, and it takes a bloody LONG time to cool. But once it does, the fan seems to settle back down. Anyone confirm my suspicion?

[Michael Eklund (tinfoilhat)]

Yep, I'm pretty certain now.
I booted the thinkpad, fan speed quickly rose to appx 3700. Then I left it alone for a half hour, wireless on and associated. The fan speed was unchanged when I looked back in on it. CPU temperature steady around 36C.
Then I disabled wireless and waited.. lo and behold, at the exact moment the reported mini-pci temp was down to 45C, the fan fell back to around 2200 RPM. Unfortunatly, this is not something that seems to be likely to happen with wireless on. I suspect I'll be taking it apart to see if there's room for a heat spreader in the near future.

[Christoph Bier (christoph-bier)]

For some time now---since 10.10 or latest BIOS upgrade (September 2010)?---my ThinkPad's fan acts like I expect it to do: It only runs at reasonable speeds if the temperature of some components rises. It spins down as temperatures drop and it even stops running when components are "cool" again.

BIOS version 3.15
EC version 1.06

[Michael Eklund (tinfoilhat)]

Once again then ... if it helps anyone..
On my x200s, this problem is definitely related to the wifi adapter.
1) Everything can be idling ever so nicely after bootup, but when you stress the CPU a bit, the fan ramps up and does not come down to level 0 - in spite of CPU going back to idle temperature. Waiting an hour does not help.
2) The fan hysteresis seems to be influenced by the mini-pcie wifi adapter. Disabling the adapter results in a drop in reported mini-pci temperature, and after a bit of cooling, the fan throttles back. Yay, though obviously it's annoying to turn off your wireless every time you want the fan to quiet down.
3) The problem seems to be solved by setting power management on through iwconfig. On the x200s, this drops the reported mini-pci temps by 6-7 degrees, and appears to let the fan throttle back along with the CPU temp. Been punishing the laptop for half a day here, and it seems to work perfectly now.

[Florian M. (flomar)]

@Michael, would you be so kind to post the iwconfig power setting that works with your thinkpad?

[Philip Hands (phil-hands)]

@Michael Eklund Thanks for persisting in commenting on this bug -- it's also present in Debian Squeeze (as one would expect from such a generic cause).

@Florian M. The command I think he's suggesting is:

  iwconfig wlan0 power on

As one can see in this (edited) output:

root@poker:~# iwconfig wlan0
...
            Power Management:off
...

root@poker:~# iwconfig wlan0 power on
root@poker:~# iwconfig wlan0
...
          Power Management:on
...

Having tried turning on power management, the result is not quite as neat and obvious for me as described by Micheal, but it seems that the same thing may well be going on, and if I turn of the wifi completely (with the switch on the side of the laptop) then it drops the temperature enough to result in a quiet fan. Power management on the wifi does drop the temperature a few degrees, but I think it's still just a little to high to let the fan throttle back in my case.

[Daniel Nögel (daniel-xn--ngel-5qa)]

I am asking myself, if it is even necessary to cool down the MiniPCI (the second sensor) to below 48°C. Right now "cat /proc/acpi/ibm/thermal" gives me values like these:

"temperatures: 35 47 -128 35 -128 -128 -128 -128 44 41 ... "

The actual hddtemp (smart) is around 38°C.

With thinkfan it'll be possible to disable (or slow down) the fan until the highest value (which is the second sensor all the time) reaches 50°C.

As my CPUs and the HDD are quite cool, one could perhaps override the fan's default behaviour with thinkfan. The only question is: How hot may the MiniPCI-device get?

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Florian M. (flomar)]

i know this bug is old and "won't fix". However I still have my X200 and I am testing Oneiric Ocelot right now. Did a dist-upgrade and didn't have any heat issues so far, it's quite noisy though. Any other experiences on this issue?