Debian Squeeze and tpfancontrol

[Niila]

Moro!

First of all, ive been using Thinkpad T42 for years and it never came to my mind that there would be dedicated Thinkpad community somewhere in the depths of internet. Some time ago I thought my T42 was getting little too old for my primary PC, so I bought used C2D 1.83GHz SXGA T60 for 300e. Awesome!

Im currently running Crunchbang Linux, and im having a hard time getting the fan work properly. Ive replaced stock heat paste with Zalmans and cleaned the fins. I haven't tried the copper plate trick yet, but my CPU temperature stays around 40C for the most time. So why does my beloved T60 want to cool down itself so badly?
When i was using XP, tp4xfancontrol used to work fine, although i got sick of its pulsating nature after a while also.

I don't know.

I have read through the wiki article about this, but there are some problems.

Code: Select all

echo level 1 | sudo tee /proc/acpi/ibm/fan

command works, except auto mode kicks on automatically after a while. How do i make it automatically go to level 1 and keep it that way?

Moving on to tpfancontrol script. This is what I get:

Code: Select all

root@thinky:/home/niila/.config# ./tp-fancontrol
2462: old priority 0, new priority -10
> Activating watchdog with delay 9 sec
> Starting dynamic fan control
./tp-fancontrol: line 242: /proc/acpi/ibm/ecdumb: No such file or directory
> Shutting down, switching to automatic fan control

Since im using 2.6.32 kernel so thinkpad_acpi driver should be installed, and it is, its just that tpfancontrol needs this ecdumb file that doesnt exist. Is there a workaround?

Moving on to Stanko's tpfc 0.5 script. Trying to install it, after

Code: Select all

make

i got bunch of "undeclared (first use in this function)"
-errors.


I really don't know.

[ThinkRob]

IIRC, tp-fancontrol requires the thinkpad_acpi module to be reloaded. I've hacked the script a bit to do this semi-automatically:

Code: Select all

Edit: removed.  If you're running an old kernel and want to use it, PM me. 

Otherwise, see the responses below.

[comps]

First, the fan speed control should be automatic. My R60 used to run on high fan RPM because of the GPU had improper drivers and was overheating.

As for ecdump, it was removed - http://lkml.org/lkml/2010/7/1/206 . The entire /proc interface has been obsolete for a long time and it's scheduled for removal at some point in the future.

Writing values to /proc/acpi/ibm/fan is allowed only if thinkpad_acpi has been modprob'ed with experimental=1 fan_control=1 and the values set shouldn't change automatically. If they do, try disabling the safety watchdog, ie. write "watchdog 0" to the /proc/acpi/ibm/fan file.

If it still doesn't work, you can use a workaround loop script that writes new values to the "fan" file.

I highly recommend Documentation/laptops/thinkpad-acpi.txt (kernel sources) for further reading. It's a pretty much complete dodumentation of the entire module. See section "Fan control and monitoring".

[ThinkRob]

First, the fan speed control should be automatic. My R60 used to run on high fan RPM because of the GPU had improper drivers and was overheating.

Agreed. I only use tp-fancontrol for my machine because the automatic fan control won't shut off the fan even if the CPU is plenty cool.

As for ecdump, it was removed - http://lkml.org/lkml/2010/7/1/206 . The entire /proc interface has been obsolete for a long time and it's scheduled for removal at some point in the future.

Yep. My script checks for its existence, but I just realized that on kernels older than, say, Lenny's (which I tested it on) that check is useless.

Ah well. I suppose I should revise that script anyways...

[comps]

First, the fan speed control should be automatic. My R60 used to run on high fan RPM because of the GPU had improper drivers and was overheating.

Agreed. I only use tp-fancontrol for my machine because the automatic fan control won't shut off the fan even if the CPU is plenty cool.

As for ecdump, it was removed - http://lkml.org/lkml/2010/7/1/206 . The entire /proc interface has been obsolete for a long time and it's scheduled for removal at some point in the future.

Yep. My script checks for its existence, but I just realized that on kernels older than, say, Lenny's (which I tested it on) that check is useless.

Ah well. I suppose I should revise that script anyways...

From what I've seen, it's unnecessarily big, I'd guess a simple small bash loop would suffice (thanks to sysfs thinkpad_acpi interface).

If you want a quick fix, ... I believe the EC dump was moved to debugfs, so you need a kernel support for that and mount it (ie. to /sys/kernel/debug). It should appear as /sys/kernel/debug/ec. It's a binary file, so expect no ASCII output, to get a value at offset 0x10, seek to 0x10 and read() one byte. Or use a C wrapper to get it - ftp://ftp.suse.com/pub/people/trenn/sources/ec/ . The fan speed offset should be 0x2f (read-only).

However it would be much easier to simply read the temperature from /sys/devices/platform/thinkpad_hwmon/temp1_input and switch() or if() in an endless while loop based on it, sleeping for 10 seconds after each read/compare.

...

When I was halfway done writing this post, I was curious how simple the script could really be. So I made you a one (appended below) using the sysfs interface (not a single /proc read or write). It turns out that 50% of the code consist of safety checks/comments

Well, "appended", the "code" tag doesn't have scrollbars and there's no "pre" tag, so ... http://pastebin.com/KC3TTKHC. Of course - feel free to tune temperatures and/or the sleep time to suit your needs. Tested on my 2.6.37 @ T500.

[ThinkRob]

Oh, there are *many* better ways to control the fan (I've got a couple lightweight daemons kicking around in my personal src directory), but the tp-fancontrol script is 1) easy to modify/examine 2) relatively well-written 3) easy to set up (just invoke it with `tp-fancontrol -d` and it does the rest, no configuration necessary.)

[Niila]

Wow, looking good!

But am i missing something?

Code: Select all

# sh fancontrolscript
: not found
: not found
: not found
: Directory nonexistente /sys/devices/platform/thinkpad_hwmon/pwm1_enable

[comps]

Code: Select all

# sh fancontrolscript
: not found
: not found
: not found

1) You have probably copied the script in a wrong way, try downloading it from http://www.sendspace.com/file/1kpblf and un-gzip-ing it:

Code: Select all

gzip -d tpfanctl.sh.gz
chmod +x tpfanctl.sh

Code: Select all

: Directory nonexistente /sys/devices/platform/thinkpad_hwmon/pwm1_enable

2) You haven't probably modprobed thinkpad_acpi with experimental=1 fan_control=1, create a new file /etc/modprobe.d/thinkpad_acpi.conf with the following line inside:

Code: Select all

options thinkpad_acpi experimental=1 fan_control=1

... and either reboot your system or re-load the thinkpad_acpi module:

Code: Select all

modprobe -r thinkpad_acpi
modprobe thinkpad_acpi

And now it should work. Make sure you're running the script as root (or somebody else who has write access to pwm1 / pwm1_enable).

Edit the script and change temperature levels if you're still getting higher fan speeds than you would like.

[Niila]

I got it now, i guess I should have saved it with .sh extension. Learning everyday.

Thanks alot dude, I love you!

One more thing, any idea how to show current fan level in my conky?

[ThinkRob]

Alright, comps, you've convinced me: I think I'm going to update fanctrld to use the sysfs interface. I prefer small C daemons to shell scripts anyways, and it's only a couple hundred lines. Plus I should have a bit more control over how many wakeups it generates...

[comps]

Alright, comps, you've convinced me: I think I'm going to update fanctrld to use the sysfs interface. I prefer small C daemons to shell scripts anyways, and it's only a couple hundred lines. Plus I should have a bit more control over how many wakeups it generates...

I wasn't trying to convince anyone The procfs interface is going to be there for some months/years at least and the sysfs interface is not oficially "stable" (in terms of file/directory names), so there's nowhere to hurry.

Sure, there are many ways to make the script/daemon more efficient, like using poll()/select() or even *notify kernel subsystem. ... or hacking thinkpad_acpi.c

[Niila]

Is there a way specify fan speeds for each level? Like say level 1 would be 2500 and level 2 3000? I noticed that fan1_input shows the speed..

[comps]

One more thing, any idea how to show current fan level in my conky?

Something like

Code: Select all

Fan level: ${execi 5 sh -c "echo $(( ($(cat /sys/devices/platform/thinkpad_hwmon/pwm1) >> 5) & 0x07 ))"}

should work. If the execi command runs shell on the command (and not fork+exec), you can simply use

Code: Select all

Fan level: ${execi 5 $(( ($(cat /sys/devices/platform/thinkpad_hwmon/pwm1) >> 5) & 0x07 ))}

Though, to be honest, conky is #1 wakeup generator, which is why I don't use it anymore on a laptop.

Is there a way specify fan speeds for each level? Like say level 1 would be 2500 and level 2 3000? I noticed that fan1_input shows the speed..

Nope, the firmware only accepts a 3-bit "number" as input, (2^3)-1 = 7:

Code: Select all

 *      Bits
 *       7      automatic mode engaged;
 *              (default operation mode of the ThinkPad)
 *              fan level is ignored in this mode.
 *       6      full speed mode (takes precedence over bit 7);
 *              not available on all thinkpads.  May disable
 *              the tachometer while the fan controller ramps up
 *              the speed (which can take up to a few *minutes*).
 *              Speeds up fan to 100% duty-cycle, which is far above
 *              the standard RPM levels.  It is not impossible that
 *              it could cause hardware damage.
 *      5-3     unused in some models.  Extra bits for fan level
 *              in others, but still useless as all values above
 *              7 map to the same speed as level 7 in these models.
 *      2-0     fan level (0..7 usually)
 *                      0x00 = stop
 *                      0x07 = max (set when temperatures critical)
 *              Some ThinkPads may have other levels, see
 *              TPACPI_FAN_WR_ACPI_FANS (X31/X40/X41)

[ThinkRob]

Sure, there are many ways to make the script/daemon more efficient, like using poll()/select() or even *notify kernel subsystem. ... or hacking thinkpad_acpi.c

Currently fanctrld wakes once every couple seconds, which isn't a big deal. I'm not sure inotify would help that actually, as I'm not sure how often the sysfs interface gets updated.

The path instability isn't a big deal, as it'd be trivial to change that as required (provided the format doesn't bounce around too.)

And I'm resisting the urge to mess with thinkpad_acpi.c. Kernel hacking is fun, and I love doing it, but userspace<->kernel coupling is bad, and IMHO fan control is definitely something that should be done out-of-kernel.

[comps]

Currently fanctrld wakes once every couple seconds, which isn't a big deal. I'm not sure inotify would help that actually, as I'm not sure how often the sysfs interface gets updated.

The path instability isn't a big deal, as it'd be trivial to change that as required (provided the format doesn't bounce around too.)

And I'm resisting the urge to mess with thinkpad_acpi.c. Kernel hacking is fun, and I love doing it, but userspace<->kernel coupling is bad, and IMHO fan control is definitely something that should be done out-of-kernel.

Looks like there has been a fan speed control change between 3.09 (which I recently flashed, Zender's version) and 3.13 T500 BIOS, the fan seems to be invoked at somewhat greater temperatures, which is fine for almost-idle load (35°C with fan vs 37-39°C without fan - good especially in dusty environments), but it fails on 50%-like loads where the keyboard is really hot and hard to type on.

So I guess I'm going to write a C daemon for myself as well, perhaps with several modes like "rather higher temperatures, but with as low fan speed as possible" and "lower temperatures at the cost of possible higher fan speeds", SIGUSR1/2 should do it. There are cases where one needs either of those modes.