ThinkWiki - User contributions [en]

Patch for controlling fan speed

2005-11-03T22:36:04Z

Pcanto:

==Overview==

This patch extends the [[ibm-acpi]] Linux kernel module to control fan speed. It can be used to reduce [[Problem with fan noise|fan noise]] (both speed and pulsing) and to decrease fan power consumption.

When this patch is applied and the <tt>ibm-acpi</tt> module is loaded with the <tt>experimental=1</tt> module parameter, the following new capabilities are added to {{path|/proc/acpi/ibm/fan}}:
* {{cmdroot|echo level LEVEL > /proc/acpi/ibm/fan}} sets a fan speed level between 0 and 7, where <tt>LEVEL</TT>=0 means fan off and <tt>LEVEL</tt>=7 is the fastest speed.
* {{cmdroot|echo level auto > /proc/acpi/ibm/fan}} tells the embedded controller to set the fan speed automatically according to system temperatures (this is the default).
* {{cmdroot|echo level disengaged > /proc/acpi/ibm/fan}} tells the embedded controller to disengage fan speed control (see specs below).
* {{cmdroot|cat /proc/acpi/ibm/fan}} shows the current fan level (in addition to the fan speed in RPM).

For example:

'''#cat /proc/acpi/ibm/fan'''
status: enabled
level: auto
speed: 4219
commands: enable, disable, level <level>
(<level> is 0-7, auto or disengaged)

'''#echo level 2 > /proc/acpi/ibm/fan'''

'''#cat /proc/acpi/ibm/fan'''
status: enabled
level: 2
speed: 3142
commands: enable, disable, level <level>
(<level> is 0-7, auto or disengaged)

This patch is best used with an [[ACPI fan control script#Variable speed control scripts|ACPI fan control script]] that monitors system temperature and sets the fan speed accordingly.

{{WARN|Overriding the system's automatic temperature control may cause permanent hardware damage. Even when using temperature monitoring software, it is not clear whether the software can access all temperature sensor accessible to the embedded controller and understand them correctly. Moreover, this patch relies on an undocumented hardware interface, and may thus have arbitrary effects (especially on models it wasn't tested on).}}

==Models on which this patch works==

* ThinkPad {{T41}}<br />Speed levels in RPM: 1-2 = ~2980, 3-5 = ~3500, 6-7 = ~4050; disengaged mode works at ~5100)
* ThinkPad {{T43}}, {{T43p}}<br />Speed levels in RPM: 1-2 = ~3300, 3-5 = ~4100, 6-7 = ~4700; disengaged mode works)

Probably many other models.

{{NOTE|If you try this patch on other models, please update this page with your results.}}

==Models on which this patch doesn't work==

* ThinkPad {{560}}, {{600E}}, {{600X}}, {{770E}}, {{770X}} (these use a different fan control interface)

==The patch==

===for ibm-acpi 0.11===

This also includes a minor fix (rename of <tt>device_add</tt>) to make [[ibm-acpi]] 0.11 compile on kernel 2.6.13.

<pre>
--- ibm-acpi-0.11-orig/ibm_acpi.c 2005-03-17 12:06:16.000000000 +0200
+++ ibm-acpi-0.11/ibm_acpi.c 2005-10-26 06:21:57.000000000 +0200
@@ -1488,11 +1488,18 @@ static int fan_read(char *p)
} else {
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_read(fan_status_offset, &status))
len += sprintf(p + len, "status:\t\tunreadable\n");
- else
+ else {
len += sprintf(p + len, "status:\t\t%s\n",
- enabled(status, 7));
+ status ? "enabled" : "disabled");
+ if (status & 0x40)
+ len += sprintf(p + len, "level:\t\tdisengaged\n");
+ else if (status & 0x80)
+ len += sprintf(p + len, "level:\t\tauto\n");
+ else
+ len += sprintf(p + len, "level:\t\t%d\n", status);
+ }

if (!acpi_ec_read(fan_rpm_offset, &lo) ||
!acpi_ec_read(fan_rpm_offset + 1, &hi))
len += sprintf(p + len, "speed:\t\tunreadable\n");
@@ -1506,9 +1513,12 @@ static int fan_read(char *p)
len += sprintf(p + len, "commands:\tlevel <level>"
" (<level> is 0-7)\n");
if (!gfan_handle)
/* all except 570, 600e/x, 770e, 770x */
- len += sprintf(p + len, "commands:\tenable, disable\n");
+ len += sprintf(p + len,
+ "commands:\tenable, disable, level <level>\n"
+ " \t(<level> is 0-7, auto"
+ "or disengaged)\n");
if (fans_handle)
/* X31, X40 */
len += sprintf(p + len, "commands:\tspeed <speed>"
" (<speed> is 0-65535)\n");
@@ -1528,17 +1538,29 @@ static int fan_write(char *buf)
/* 570, 770x-JL */
if (!acpi_evalf(sfan_handle, NULL, NULL, "vd", level))
return -EIO;
} else if (!gfan_handle &&
- strlencmp(cmd, "enable") == 0) {
+ ( (strlencmp(cmd, "enable") == 0) ||
+ (strlencmp(cmd, "level auto") == 0) ) ) {
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_write(fan_status_offset, 0x80))
return -EIO;
} else if (!gfan_handle &&
strlencmp(cmd, "disable") == 0) {
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_write(fan_status_offset, 0x00))
return -EIO;
+ } else if (!gfan_handle &&
+ strlencmp(cmd, "level disengaged") == 0) {
+ /* all except 570, 600e/x, 770e, 770x */
+ if (!acpi_ec_write(fan_status_offset, 0x40))
+ return -EIO;
+ } else if (!gfan_handle &&
+ sscanf(cmd, "level %d", &level) == 1 &&
+ level >=0 && level <= 7) {
+ /* all except 570, 600e/x, 770e, 770x */
+ if (!acpi_ec_write(fan_status_offset, level))
+ return -EIO;
} else if (fans_handle &&
sscanf(cmd, "speed %d", &speed) == 1 &&
speed >= 0 && speed <= 65535) {
/* X31, X40 */
@@ -1751,9 +1773,9 @@ static int __init setup_notify(struct ib

return 0;
}

-static int device_add(struct acpi_device *device)
+static int ibmacpi_device_add(struct acpi_device *device)
{
return 0;
}

@@ -1769,9 +1791,9 @@ static int __init register_driver(struct

memset(ibm->driver, 0, sizeof(struct acpi_driver));
sprintf(ibm->driver->name, "%s/%s", IBM_NAME, ibm->name);
ibm->driver->ids = ibm->hid;
- ibm->driver->ops.add = &device_add;
+ ibm->driver->ops.add = &ibmacpi_device_add;

ret = acpi_bus_register_driver(ibm->driver);
if (ret < 0) {
printk(IBM_ERR "acpi_bus_register_driver(%s) failed: %d\n",
</pre>

The [[User:Thinker|author]] disclaims all warranty for this patch, and releases it to the public domain (meaning you may use and further distribute it under any terms you wish, including incorporating it into other software).

===for ibm-acpi 0.12a as found in kernel 2.6.14===

A slightly modified version which also keeps the lines in the format expected by the gkrellm plugin.

<pre>
--- drivers/acpi/ibm_acpi.c.orig 2005-11-01 19:47:44.262270250 +0100
+++ drivers/acpi/ibm_acpi.c 2005-11-01 20:16:16.081252250 +0100
@@ -1465,6 +1465,7 @@ static int fan_read(char *p)
{
int len = 0;
int s;
+ char status_read = 0;
u8 lo, hi, status;

if (gfan_handle) {
@@ -1477,9 +1478,11 @@ static int fan_read(char *p)
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_read(fan_status_offset, &status))
len += sprintf(p + len, "status:\t\tunreadable\n");
- else
+ else {
len += sprintf(p + len, "status:\t\t%s\n",
- enabled(status, 7));
+ status ? "enabled" : "disabled");
+ status_read = 1;
+ }

if (!acpi_ec_read(fan_rpm_offset, &lo) ||
!acpi_ec_read(fan_rpm_offset + 1, &hi))
@@ -1487,6 +1490,14 @@ static int fan_read(char *p)
else
len += sprintf(p + len, "speed:\t\t%d\n",
(hi << 8) + lo);
+ if (status_read) {
+ if (status & 0x40)
+ len += sprintf(p + len, "level:\t\tdisengaged\n");
+ else if (status & 0x80)
+ len += sprintf(p + len, "level:\t\tauto\n");
+ else
+ len += sprintf(p + len, "level:\t\t%d\n", status);
+ }
}

if (sfan_handle)
@@ -1495,7 +1506,10 @@ static int fan_read(char *p)
" (<level> is 0-7)\n");
if (!gfan_handle)
/* all except 570, 600e/x, 770e, 770x */
- len += sprintf(p + len, "commands:\tenable, disable\n");
+ len += sprintf(p + len,
+ "commands:\tenable, disable, level <level>\n"
+ " \t(<level> is 0-7, auto "
+ "or disengaged)\n");
if (fans_handle)
/* X31, X40 */
len += sprintf(p + len, "commands:\tspeed <speed>"
@@ -1516,7 +1530,8 @@ static int fan_write(char *buf)
/* 570, 770x-JL */
if (!acpi_evalf(sfan_handle, NULL, NULL, "vd", level))
return -EIO;
- } else if (!gfan_handle && strlencmp(cmd, "enable") == 0) {
+ } else if (!gfan_handle && ( (strlencmp(cmd, "enable") == 0) ||
+ (strlencmp(cmd, "level auto") == 0) ) ) {
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_write(fan_status_offset, 0x80))
return -EIO;
@@ -1524,6 +1539,17 @@ static int fan_write(char *buf)
/* all except 570, 600e/x, 770e, 770x */
if (!acpi_ec_write(fan_status_offset, 0x00))
return -EIO;
+ } else if (!gfan_handle &&
+ strlencmp(cmd, "level disengaged") == 0) {
+ /* all except 570, 600e/x, 770e, 770x */
+ if (!acpi_ec_write(fan_status_offset, 0x40))
+ return -EIO;
+ } else if (!gfan_handle &&
+ sscanf(cmd, "level %d", &level) == 1 &&
+ level >=0 && level <= 7) {
+ /* all except 570, 600e/x, 770e, 770x */
+ if (!acpi_ec_write(fan_status_offset, level))
+ return -EIO;
} else if (fans_handle &&
sscanf(cmd, "speed %d", &speed) == 1 &&
speed >= 0 && speed <= 65535) {
</pre>

The [[User:spiney|author]] disclaims all warranty for this patch, and releases it to the public domain (meaning you may use and further distribute it under any terms you wish, including incorporating it into other software).

==Controlling the fan without this patch==

If you have the [[ibm-acpi]] module loaded with <tt>experimental=1</tt>, you can control the fan without patching the kernel by directly writing to the relevant embedded controller register using {{path|/proc/acpi/ibm/ecdump}}.

For example:

{{cmdroot|echo 0x2F 0x04 > /proc/acpi/ibm/ecdump}}

will set the fan to manual mode 4 (see the specifications below).

==Hardware specs==

The patch relies on the following hardware behavior, which was discovered experimentally and neither provided by nor confirmed by IBM/Lenovo. The following description may be inaccurate and may vary by model (see list of models above). The terminology probably does not match the one used by IBM/Lenovo engineers.

ACPI DSDT register _SB.PCI0.LPC.EC.HFSP (8 bits, offset 0x2F in the <tt>EmbeddedController</tt> address space)
is read/writable and has the following meaning:

7 6 5 4 3 2 1 0
| | \_________/
| | |
| | +--------- manual fan speed level (0=disable, 1=min, ..., 7=max)
| +---------------- disengaged (0=normal, 1=disengaged, overrides all)
+------------------ automatic fan speed control (0=manual, 1=automatic, overrides manual)

Manual speed levels 8-63 yield the same behavior as level 7, and the the ACPI DSDT uses level 7 for the emergency mode it enters upon critical CPU/GPU temperature, so apparently 7 is the real maximum level.

When bit 7 is on, the embedded controller sets the fan speed automatically according to system temperaturesand some unknown algorithm. This overrides manual control.

When bit 6 is on, the embedded controller does not read the fan RPM (hence <tt>EmbeddedController</tt> offset 0x84 is not updated), and does not maintain a stable fan speed. This overrides manual and automatic control. When disengaged mode is entered the fan speed is not immediately changed (except if the fan was disabed, in which case it is turned on at a low level). However, once in disengaged mode, fan speed will slowly increase to ''beyond'' the maximum manual level (this may cause hardware damage!).

{{HINT|Apparently the [[Problem with fan noise|pulsing fan noise]] experienced by some users can be cured by repeatedly running 2-4 seconds of manual control followed by 0.5-1 seconds of disengaged mode. The pulse occurs when the the embedded controller computes the fan speed and adjusts the fan voltage adaptively every few seconds (~4.8sec for the ThinkPad T43); the aforementioned mode switching doesn't give it a chance to do so. One of the [[ACPI fan control script#Variable speed control scripts|ACPI fan control scripts]] implements this solution.}}

[[Category:Patches]]

Problem with high power drain in ACPI sleep

2005-06-15T15:57:12Z

Pcanto:

Information about the problem of too high power drain in ACPI sleep mode.

==Problem description==
Several people realised that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.

==Affected Models==
*Different symptoms have been reported for different models. In some models the origin of the power drain is obvious ([[Problem with LCD backlight remaining on during ACPI sleep|backlight on during suspend]]), in other models there is no obvious reason.
*On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.
*The T4x thinkpad series (T40, T40p, T41, T41p, T42, T42p, T43, T43p) suspends to ram just fine, and there are no components that are obviously left powered up. The [[UltraBay]] and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF).
*One thing to keep in mind, though, is that some models only suffer this problem with certain software. For example, my T40 (2374-94U) has the high power drain issue with the stock Fedora Core 3. If I use one of the more recent kernels from [http://www.sas.upenn.edu/~vbraun/computing/T41/kernel.html Volker Braun's T-41 site], everything (suspend-to-RAM, suspend-to-disk) works just fine and my battery life seems much better than APM. In other words, just because you see this problem with your ThinkPad with your current software does not mean that your ThinkPad will doomed to always be affected. There are similar solutions for Debian-based systems too.

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

{| border="1" cellspacing="0" cellpadding="2"
|-
! style="vertical-align:top;background-color:#ffcfbc;" | affected models
! style="vertical-align:top;background-color:#cfefcf;" | unaffected models
|-
| style="vertical-align:top;background-color:#fff0e0;" |
* {{R40}}
** 2722-5MG
** 2722-B3G
** 2897-GWU
* {{R50}}
** 1829-7RG
** 1829-6DM
** 1836-3SU
* {{R51}}
** 1829-9MG
** 1829-EHG
** 1830-DG4
** 1836-Q6U
* {{T23}}
**2647-???
* {{T30}}
** 2366-81A
** 2366-97U
*{{T40}}
**2373-MU3
**2373-82U
**2373-92U
**2373-22G
**2373-19G
**2373-A1U
*{{T40p}}
**2373-G1U
**2373-G3U
**2373-G3G
**2373-G1G
**2373-G5G
* {{T41}}
**2379-DJU
**2373-9HU
**2373-4FG
**2373-4PG
**2373-1FG
**2373-2FG
**2373-6U4
**2373-7JU
**2373-CY0
* {{T41p}}
**2373-9FU
* {{T42}}
**2378-DUU
**2373-FWG
**[[2373-6ZG]]
* {{X21}}
| style="vertical-align:top;background-color:#e9f9e9;" |
*[[:Category:R50p | R50p]]
*[[:Category:T41 | T41]]
**2373-GEU
*[[:Category:T41p | T41p]]
**2373-GKG
**2373-GGG
**[[2373-GHG]]
*[[:Category:T42p | T42p]]
**[[2373-HTG]]
**[[2373-W6M]]
**[[2373-GTG]]
**[[2373-GXG]]
**2373-KXM
*[[:Category:T42 | T42]]
**[[2378-FVU]]
**[[2373-WBZ]]
*[[:Category:X40 | X40]]
**2371
*[[:Category:A22m | A22m]]
**2628
|}

==Affected Operating Systems==

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

==Status==
*The cause of the problem is not really clear, yet.

*A faulty DSDT might be responsible for the phenomenon. The thinkpad T4x DSDT has a few small bugs, none of which should cause the extra power drain. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)

*There is a interesting discussion taking place in the [http://bugme.osdl.org/show_bug.cgi?id=3022 OSDL Bugzilla].

Update: it seems that the most significant difference can be made by properly turning off the video chip.

==Solutions==
===For Thinkpads with Radeon graphic driver===
A proposed solution is to remove the CONFIG_PPC_PMAC condition for enabling D2 sleep in drivers/video/aty/radeon_pm.c as discussed in [http://bugme.osdl.org/show_bug.cgi?id=3022 kernel bug 3022]. There you can also find patches doing this. The patches divide into unconditional ones like [http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/patch-2.6.11-rc2-radeonfb-D2.patch.bz2 this one for 2.6.11-rc2] and conditional ones. The conditional ones only do D2 on models where it has been reported to work, the unconditional ones force D2 sleep on every model and you might experience hangs on resume with those.

For [[:Category:Fedora Core | Fedora Core]] there's are precompiled patched kernels (2.6.11-rc2 based) available:
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/kernel-DANGEROUS-T4x-2.6.11-8.i386.rpm kernel with unconditional patch applied]
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/kernel-T4x-2.6.11-8.i386.rpm kernel with conditional patch applied].

If you try, please send the result (hang yes/no, battery drain yes/no) with the precise model number (for example, I have a IBM thinkpad T41 2379-DJU) to <tt>vbraun at physics dot upenn dot edu</tt>, it would be nice if your subject line would include "RADEONFB:" to make sure that I do not miss any emails.

{{WARN|This solution enables doing suspend-to-D2 on non-PPC-machines, which is not tested at all and supposed to be the wrong thing to do! Be careful and have a look at the discussion for kernel bug 3022 (see above) before applying the patch.}}

===for other models===
Nothing yet.