Most recent kernel where this bug did not occur: Distribution: Fedora Core 4 Hardware Environment: Fujitsu-Siemens AMILO L1310G Software Environment: Problem Description:The problem is that fan either works non-stop or doesn't work at all... And even when the fan is not working both /proc/acpi/fan/FAN0/state and /proc/acpi/fan/FAN1/state read "status: on". However, /proc/acpi/thermal_zone/THRM/state is changing correctly according to temperature changes and current setting in trip_points... but it has nothing to do with the fan. Steps to reproduce:
Created attachment 6073 [details] acpidump
Created attachment 6074 [details] dmesg output
Created attachment 6075 [details] dmidecode output
Created attachment 6076 [details] /proc/interrupts
Created attachment 6077 [details] lspci -vv
Is is true that this has always been true for all tested versions of Linux, or did this used to work and has stopped working? It is possible that this box doesn't have ACPI fan control. assinging to Konstantin to check.
I have tested 2.6.11 (FC4), 2.6.12 (FC4), 2.6.13 (vanilla) and 2.6.13-2 (vanilla) - the same results. Sometimes, however, echo'ing 0 or 3 to /proc/acpi/fan/FAN1/state can start/stop the fan, but this file always says "status: on". MS Windows' Device Manager states that hardware has acpi fan control (D0 and D3).
Created attachment 6780 [details] DSDT patch Here is the DSDT patch, which should fix your problem. The instructions for DSDT fixing are available from here: http://forums.gentoo.org/viewtopic.php?t=122145 The issue is that ACPI first tries to read device power state from _PSC method, if this is unsuccessful, it evaluates device state from the power resources, defined for this device. In your DSDT the _PSC is defined with 0x00 value, and never being updated later, so the device state is always reported ON. With this patch the things should work as expected.
[root@localhost ~]# cat /proc/acpi/fan/FAN?/state status: off status: off [root@localhost ~]# cat /proc/acpi/thermal_zone/THRM/* cooling mode: active polling frequency: 1 seconds state: ok temperature: 46 C critical (S5): 100 C passive: 90 C: tc1=3 tc2=1 tsp=80 devices=0xdbd6fe68 active[0]: 90 C: devices=0xdbd67828 active[1]: 55 C: devices=0xdbd67728 ... and the fan keeps spinning:(
Were you able to start/stop the fan echo'ing 0 or 3 to /proc/acpi/fan/FAN1/state? If so, do the FAN?/state files change accordingly?
Ok, echo'ing 3 or 0 to FAN?/state changes those files correctly, but sometimes (i can't figure out what is the cause) fan doesn't physically change its state...
Created attachment 7576 [details] DSDT patch w/debug prints Here is the above patch with debugging prints inserted on _ON/_OFF methods execution. This should show the fan state (as evaluated by _STA method) after _ON/_OFF method invocation. The debug for ACPI should be enabled, you should see the strings like "------------ PFN0._OFF 0" in dmesg output. It's interesting to see what happens on trip point crossing, on echo'ing 0/3 to fan/*/state file, etc...
a clear dup of bug# 8049... *** This bug has been marked as a duplicate of bug 8049 ***