Bug 8049

Summary: Fan does not start - Fujitsu-Siemens Amilo l1310g
Product: ACPI Reporter: Lorincz Andras (andras.lorincz)
Component: BIOSAssignee: Zhang Rui (rui.zhang)
Status: CLOSED DUPLICATE    
Severity: normal CC: acpi-bugzilla, peryklez, trenn
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.20 Subsystem:
Regression: --- Bisected commit-id:
Attachments: The output of acpidump
Don't use bogus _PSC method in fan device
patch to select fan state source
updated patch
Yet another updated patch
Output of dmesg
Corrected patch
dmesg output
dmidecode output
dmesg output on kernel 2.6.25.6 with patch from comment 41
try the debug patch
dmesg output when the fan isn't started

Description Lorincz Andras 2007-02-21 09:35:42 UTC
Most recent kernel where this bug did *NOT* occur: happens on every kernel I
tried (begining with 2.6.18)
Distribution: debian testing
Hardware Environment: fujitsu-siemens amilo l1310g laptop
Software Environment:
Problem Description: The CPU fan doesn't ever start spinning even if some CPU
intensive task is run. If I run watch -n1 cat /proc/acpi/fan/*/state
/proc/acpi/thermal_zone/*/{temperature,trip_points} then I get this:

status:                  on
status:                  on
temperature:             72 C
critical (S5):           105 C
passive:                 79 C: tc1=3 tc2=1 tsp=80 devices=0xf7e9c720
active[0]:               65 C: devices=0xc17e4d9c
active[1]:               55 C: devices=0xc17e4d38

The status reported is always on regardless of the temperature.

Steps to reproduce: run some CPU intensive task to heat up CPU
Comment 1 Alexey Starikovskiy 2007-02-21 09:40:10 UTC
Could you please check the 2.6.21-rc1?
Also output of acpidump will generally help to understand you problem better.
Comment 2 Lorincz Andras 2007-02-21 09:41:37 UTC
Created attachment 10484 [details]
The output of acpidump
Comment 3 Lorincz Andras 2007-02-22 10:07:15 UTC
Nothing changes with 2.6.21-rc1
Comment 4 Alexey Starikovskiy 2007-02-22 10:37:05 UTC
Created attachment 10498 [details]
Don't use bogus _PSC method in fan device

bad news: your BIOS is broken -- it says that your fan is always on regardless
of its real state (via _PSC object).
good news: there are control methods to turn it off/on, so if fan driver
ignores _PSC, you should be able to control fan. Patch does exactly this, tells
ACPI, that you are not interested in value of _PSC and want direct control...
Please try.
Comment 5 Lorincz Andras 2007-02-22 11:55:56 UTC
Thanks for your help.

good news: it almost works well

bad news: when the system boots the fan continues spinning when the fan.ko is
loaded even if the temperature is bellow threshold. The fan will stop if the
temperature raises over threshold and then back bellow threshold. From that
point on the fan is switching on and off properly.

P.S. By the way, I think that I can apply this patch to 2.6.20 also, couldn't I?
Comment 6 Alexey Starikovskiy 2007-02-22 12:00:34 UTC
yes, you could.
Comment 7 Lorincz Andras 2007-02-22 12:14:43 UTC
Well, is it appliable to 2.6.19.4 also? I need 2.6.19 because of the ati
proprietary drivers.
Comment 8 Alexey Starikovskiy 2007-02-22 12:17:16 UTC
I think you are safe past 2.6.12 or so...
Comment 9 Lorincz Andras 2007-02-24 04:43:35 UTC
Isn't there a way by which I can manage to stop the fan on boot time, because as
I said that the CPU temperature must reach for a very first time the threshold
temperature for the cooler to work properly. Thanks.
Comment 10 Alexey Starikovskiy 2007-02-24 07:33:46 UTC
echo 0 > /proc/acpi/fan/XXX/state
echo 3 > /proc/acpi/fan/XXX/state
in your case.
Comment 11 Konstantin Karasyov 2007-02-28 10:21:57 UTC
Created attachment 10556 [details]
patch to select fan state source

This patch checks the consistency of fan state returned from _PSC object. If
the state is not consistent and state acquisition from another source is
possible - disable fan state acquisition from _PSC object.
Comment 12 Lorincz Andras 2007-02-28 23:25:45 UTC
On which versions of kernels can be the patch applied?
Comment 13 Alexey Starikovskiy 2007-02-28 23:27:28 UTC
latest git
Comment 14 Lorincz Andras 2007-03-05 23:50:07 UTC
Will this patch be included in some kernel release?
Comment 15 Konstantin Karasyov 2007-03-07 06:16:27 UTC
Before that someone should confirm it's useful :)

Do you have any problems applying this patch? Please, don't hesitate to ask if 
you have any difficulties, need assistance, etc...
Comment 16 Lorincz Andras 2007-03-07 13:10:00 UTC
You said that I should apply this patch to the latest git... how can I obtain
the latest git? Should I download patch-2.6.21-rc3-git1.bz2, apply it against
2.6.20? And then apply your patch?
Comment 17 Konstantin Karasyov 2007-03-09 01:02:00 UTC
Yes.
Comment 18 Lorincz Andras 2007-03-09 02:08:20 UTC
Unfotunately I have some problems applying the git patch. I apply the patch 
this way:

cd /usr/src/linux
patch -p1 < patch-2.6.21-rc3-git4

but I get something like this:

patching file Documentation/kernel-parameters.txt
Hunk #1 succeeded at 78 (offset -1 lines).
Hunk #2 succeeded at 477 (offset -9 lines).
Hunk #3 succeeded at 1726 (offset -59 lines).
patching file Documentation/sparse.txt
patching file Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
patching file arch/avr32/kernel/ptrace.c
patching file arch/avr32/kernel/traps.c
patching file arch/avr32/mach-at32ap/at32ap7000.c
Hunk #1 FAILED at 752.
1 out of 1 hunk FAILED -- saving rejects to file arch/avr32/mach-
at32ap/at32ap7000.c.rej
patching file arch/avr32/mm/cache.c
Hunk #1 succeeded at 105 (offset -16 lines).
patching file arch/i386/kernel/acpi/earlyquirk.c
Hunk #1 FAILED at 14.
Hunk #2 FAILED at 26.
2 out of 2 hunks FAILED -- saving rejects to file 
arch/i386/kernel/acpi/earlyquirk.c.rej
patching file arch/i386/kernel/smpboot.c
Hunk #1 succeeded at 50 (offset 5 lines).
Hunk #2 succeeded at 1438 (offset 159 lines).
Hunk #3 FAILED at 1458.
1 out of 3 hunks FAILED -- saving rejects to file 
arch/i386/kernel/smpboot.c.rej
patching file arch/ia64/kernel/asm-offsets.c
patching file arch/ia64/kernel/efi.c
Hunk #2 FAILED at 1015.
1 out of 2 hunks FAILED -- saving rejects to file arch/ia64/kernel/efi.c.rej
patching file arch/ia64/kernel/fsys.S
patching file arch/ia64/kernel/iosapic.c
patching file arch/ia64/kernel/setup.c
patching file arch/ia64/sn/kernel/irq.c
patching file arch/mips/arc/init.c
Hunk #1 FAILED at 23.
1 out of 1 hunk FAILED -- saving rejects to file arch/mips/arc/init.c.rej
patching file arch/mips/kernel/linux32.c
Reversed (or previously applied) patch detected!  Assume -R? [n]

I gave y to all but at a moment patch required me:

File to patch:

So I think it doesn't find some file that he wants to patch. So I think I need 
some help here.
Comment 19 Alexey Starikovskiy 2007-03-09 09:02:08 UTC
Andras,
you need to get rc3 patch applied first.
Comment 20 Lorincz Andras 2007-03-11 00:39:38 UTC
Now the first 2 patches work (rc3 and rc3-git6), but some problem with the 
patch from you :(

I get this:

patching file drivers/acpi/fan.c
patching file drivers/acpi/power.c
Reversed (or previously applied) patch detected!  Assume -R? [n] y
Hunk #2 FAILED at 468.
1 out of 2 hunks FAILED -- saving rejects to file drivers/acpi/power.c.rej

Comment 21 Konstantin Karasyov 2007-03-12 05:46:37 UTC
Created attachment 10716 [details]
updated patch

try this one - it is updated for the latest git
Comment 22 Lorincz Andras 2007-03-12 12:25:35 UTC
The latest patch works but I still have to do

echo 0 > /proc/acpi/fan/FAN1/state
echo 3 > /proc/acpi/fan/FAN1/state

in order to stop the cooler at startup if the temperature is bellow 55 (as I
explained at comment 5)
Comment 23 Len Brown 2007-03-12 12:51:53 UTC
re-opening, pending updated patch from Konstantin
Comment 24 Konstantin Karasyov 2007-03-19 07:03:09 UTC
Could you please send the output of dmesg?
Also, what are the states of the fans when they are spinning on startup (and 
the temperature is below 55 C)?
Comment 25 Konstantin Karasyov 2007-03-19 09:39:44 UTC
Created attachment 10837 [details]
Yet another updated patch

Please, also try this patch to see if it helps.
Hopefully it should solve the startup issue.

If it's not - please, send the dmesg output with acpi_debug turned on.
Comment 26 Lorincz Andras 2007-03-19 13:19:03 UTC
Created attachment 10845 [details]
Output of dmesg

The same result. When the system is turned on, the fan is spinning by default
and it's not stopped on load of the fan module even if temperature is bellow
55C. In this situation the state reported in /proc/acpi/fan/FAN1/state is off
although the fan is spinning. I'm attaching you the output of dmesg. I'm not
sure what you meant by "acpi_debug turned on" but I enabled debug statement in
the kernel configuration before compilation and also added the
acpi_debug=0xffffffff kernel parameter in grub.
Comment 27 Konstantin Karasyov 2007-03-20 17:19:34 UTC
Created attachment 10876 [details]
Corrected patch

Could you try this one to see if the things differ.
Now the fan states are being re-read after "failed" switch attempt.

If it doesn't work too, I'd like to see dmesg, and the states of the fans on
startup.
Comment 28 Lorincz Andras 2007-03-21 11:53:06 UTC
Created attachment 10904 [details]
dmesg output

The fan still doesn't stop on startup. You can find the dmesg output attached
and the state reported for the fans are:

root@lorand-nb:~# cat /proc/acpi/fan/FAN*/state
status: 		 off
status: 		 ERROR
Comment 29 Lorincz Andras 2007-04-11 04:21:46 UTC
Well, if my laptop is so ill designed, I would be pleased if some patch would 
be included in the kernel even if that little script has to be run on startup 
to stop the cooler if the temperature is bellow threshold. Or such patch 
wouldn't be accepted in the kernel?
Comment 30 Fu Michael 2007-11-06 05:51:20 UTC
Len, what should we do with the patch in c#27?
Comment 31 Fu Michael 2007-11-06 05:52:09 UTC
*** Bug 5289 has been marked as a duplicate of this bug. ***
Comment 32 Len Brown 2008-01-06 22:16:05 UTC
moving to BIOS category, since this fan issue boils down
to working around a bogus BIOS _PSC.
Comment 33 Zhang Rui 2008-03-23 23:46:16 UTC
Shouldn't we close this bug?
If we don't want to push the workaround patch upstream, we should reject this bug and mark it as WILL_NOT_FIX.
Comment 34 Len Brown 2008-03-25 17:57:47 UTC
I don't think we should push this workaround patch,
since it has not been reported to automatically make the system here
or in bug 5289 work.

The BIOS clearly isn't following the ACPI spec,
but presumably the fan works properly on Windows...

I don't see WMI's PNP0C14 in the AML, so it can't be that.

Can somebody confirm that fan control works on these boxes when
running Windows?
Comment 35 Lorincz Andras 2008-03-27 01:03:27 UTC
I received this laptop with Windows XP Home Edition and the fan control works properly. If I can give you some information from windows, I'm looking forward to help you as I would like linux to work on my laptop. I also can test patches you make because I have debian installed, just I don't use it because of the problem.
Comment 36 Thomas Renninger 2008-03-27 03:43:20 UTC
I like the patch from Alexey and IMO this flag should get a boot or module paramater.
The "Check fan consitency" check in comment #27 locks a bit too intrusive.
Maybe this still can be slimmed/broken down and integrated in the boot/module param variable?
The bug is rather old now anyway. The DSDT should be compared with a newer Fujitsu ones (similar model) to evaluate whether these models still need something to provide proper fan management.
-> Taking the bug for now. If I find the time, I try to come up with something.
Comment 37 Thomas Renninger 2008-03-27 04:01:06 UTC
Lorincz, can you pls do a BIOS update first and retry.
If you still have the problem, pls send dmidecode.
You may also want to search the web for related reports.
Having more affected systems increases the chance of mainline integration and we possibly could set up a sane whitelist to use the parameter automatically using dmi info.
Comment 38 Lorincz Andras 2008-03-28 00:59:51 UTC
I've updated to the latest BIOS and tried with kernel 2.6.24 but no success. The cooler spins and doesn't stop until I launch

"echo 3 > /proc/acpi/fan/FAN1/state"

this stops the cooler but after that it won't ever start even if I launch

"echo 0 > /proc/acpi/fan/FAN1/state"

I'm not sure if you wanted me to test with the latest kernel or if I should have  apply some of the patches above... if so please specify which kernel version and what patch to use.

Anyway, I think you just wanted me to se whether the latest BIOS does any improvement. I will send you today the output of dmidecode.
Comment 39 Lorincz Andras 2008-03-28 13:10:19 UTC
Created attachment 15482 [details]
dmidecode output

Here is the dmidecode output.
Comment 40 Shaohua 2008-05-22 19:21:43 UTC
Rui, can we check if windows uses _PSC? If not, I thought we can push the workaround.
Comment 41 ykzhao 2008-07-02 23:26:11 UTC
Hi, Andras
    Will you please try the workaround patch in 
    http://bugzilla.kernel.org/show_bug.cgi?id=11000#c20 
    and see whether it can work for you? 
   (Note: please add the boot option of "acpi.power_nocheck=1")
    Thanks.
Comment 42 Lorincz Andras 2008-07-03 14:09:03 UTC
Created attachment 16725 [details]
dmesg output on kernel 2.6.25.6 with patch from comment 41

Hello,

The patch is working and I can manually start and stop the fan. Though I have to mention that the cooler spins after startup whatever is the temperature, even if the temperature is bellow 55C. If I stop the fan, after that, the cooler works ok, i.e. it starts at 55C and stops if the temperature drops bellow 50C. I will further test and see if there is any strange behaviour. So it is working now  perfectly if a script is created to handle the startup issue.
Comment 43 ykzhao 2008-07-06 19:20:28 UTC
Thanks for the test.
According to the description it seems that the FAN device can be turned on/off correctly after the patch is applied.

About the issue that the fan is always turned on in the boot phase,  IMO this is related with the BIOS. When the FAN device driver is loaded, OS will check the power state related with the FAN device and turn on/off the FAN device.(For example: If the power state of the _PSC/_STA object is on, OS will trun on the FAN device.). But unfortunately the FAN is not turned off in the course of loading thermal driver even if the temperature is below the corresponding trip points. Maybe it is reasonable that thermal driver turns off the FAN cooling device if the temperatur is below the corresponding trip point.

Thanks
Comment 44 Lorincz Andras 2008-07-07 03:28:55 UTC
Yes, there are 2 possibilities: either the driver stops the cooler on startup if the temperature is bellow threshold, or a startup script should be created which handles this. From the average user point of view the first one is better.

Will be this patch included in future kernels, if so, when?
Comment 45 ykzhao 2008-07-07 19:58:25 UTC
Created attachment 16765 [details]
try the debug patch

Will you please try the debug patch and see whether the FAN device can be turned off in boot-phase? (Note:  the thermal driver should be loaded).

In the debug patch OS will set the FAN cooling device to the correct state when loading the thermal driver.

Of course the patch in comment #41 is also required.

Thanks.
Comment 46 Lorincz Andras 2008-07-08 23:56:00 UTC
Everything is working fine now.
Comment 47 ykzhao 2008-07-14 00:38:54 UTC
Thanks for the test.
After the patches are applied, the system can work well. So the bug can be marked as the resovled .IMO.

I have sent the patches to acpi mail list. But we will have to wait for some time before they can be merged into upstream kernel.

Thanks.
Comment 48 Zhang Rui 2008-07-14 00:49:21 UTC
Patches already available.
we can close it once the patches hit upstream.
Comment 49 Lorincz Andras 2008-07-23 00:14:34 UTC
It looks like this still needs a little adjustement: the fan stops on startup if appropriate but doesn't start automatically after the threshold is reached (55C). It is needed to launch:

echo 3 > /proc/acpi/fan/FAN1/state;echo 0 > /proc/acpi/fan/FAN1/state

After this it is working as expected i.e. fan is turning on and off as it should.
If at startup the processor is heated and the fan doesn't need to be stopped then it is working correctly.
Comment 50 ykzhao 2008-07-23 01:35:09 UTC
Hi, Lorincz
    Do you mean that the fan can't be automatically started although the threshold is reached after the patch in comment #41 and #45 is applied?
    The patch in comment #45 will only turn off the Fan device in the boot phase if the temperature is below the threshold. It doesn't care when and how to turn on the device. 
Comment 51 Lorincz Andras 2008-07-23 04:05:42 UTC
Hi,

There are 2 situations (both patches applied):

 1. The temperature is above 50C on startup. In this case the fan is started and stopped automatically as expected, so in this case there is no problem and the fan is working well without any manual intervention.

 2. The temperature is bellow 50C on startup. In this case the fan is stopped as expected. The fan isn't started automatically if the temperature exceeds 55C. It is needed to manually launch this:

echo 3 > /proc/acpi/fan/FAN1/state;echo 0 > /proc/acpi/fan/FAN1/state

But this is needed only ONCE because after that the fan is stopped and started automatically as expected and no further manual intervention is needed.

P.S. The thresholds are 55C at which point the fan starts, and 50C at which point the fan stops.
Comment 52 ykzhao 2008-07-23 18:54:06 UTC
Hi, Lorincz
    Will you please confirm whether the boot option of "acpi.power_nocheck=1" is added in your test?
   Thanks.
Comment 53 Lorincz Andras 2008-07-24 00:16:55 UTC
Hi,

Yes, the boot option is there.
I noticed a weird thing: if I start windows and then reboot into linux then in the  secound scenario from comment 51 the cooler is working fine, maybe windows leaves the fan in some state and that's why. But if I switch off completely and then power on again the laptop and boot directly in linux, scenario 2 from comment 51 will happen.
Comment 54 ykzhao 2008-07-24 01:57:55 UTC
Hi, Lorincz
   According to your description it seems very weird. 
   Will you please enable CONFIG_ACPI_DEBUG in kernel configuration and add the boot option of "acpi.debug_layer=0x04010004 acpi.debug_level=0x08000017"?
   After the temperature reaches the threshold,  please attach the output of dmesg.
   Of course the patch and boot option are also required.
   Thanks.
Comment 55 Lorincz Andras 2008-07-24 12:13:10 UTC
Created attachment 16966 [details]
dmesg output when the fan isn't started

I'm really confused because it's spooky what's happening. This evening I sat down to get the dmesg as you requested and guess what the fan was working properly: it was shutdown at boot time because the temperature was bellow threshold but it was started properly when the processors heated up... so it was working properly. Then I restarted several times and even powered off and on and everything was fine. This was annoying because I could not reproduce the situation. Then I restarted and booted windows, then restarted again and booted debian again and this time the problem appeared. So in my opinion windows is doing something which confuses the kernel. I will try to determine the exact situation when this problem appears.
Comment 56 Lorincz Andras 2008-08-07 13:31:31 UTC
Hello,

May I ask whether the patch from comment 41 is or not available in some kernel release and if not then for when is it planned to be included? Even if the initial status of the fan is not the proper one on startup, at least after proper initialization at startup the fan is working well after, so it would be reasonable to include the patch in the kernel releases, well... this is my opinion :)
Comment 57 ykzhao 2008-08-07 18:13:54 UTC
Hi, Lorincz
    Sorry that now the patch is not merged into the upstream kernel. But I will try to push them into upstream kernel.
    Thanks.
Comment 58 Len Brown 2008-10-16 23:57:29 UTC

*** This bug has been marked as a duplicate of bug 11000 ***