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
Could you please check the 2.6.21-rc1? Also output of acpidump will generally help to understand you problem better.
Created attachment 10484 [details] The output of acpidump
Nothing changes with 2.6.21-rc1
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.
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?
yes, you could.
Well, is it appliable to 2.6.19.4 also? I need 2.6.19 because of the ati proprietary drivers.
I think you are safe past 2.6.12 or so...
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.
echo 0 > /proc/acpi/fan/XXX/state echo 3 > /proc/acpi/fan/XXX/state in your case.
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.
On which versions of kernels can be the patch applied?
latest git
Will this patch be included in some kernel release?
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...
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?
Yes.
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.
Andras, you need to get rc3 patch applied first.
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
Created attachment 10716 [details] updated patch try this one - it is updated for the latest git
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)
re-opening, pending updated patch from Konstantin
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)?
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.
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.
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.
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
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?
Len, what should we do with the patch in c#27?
*** Bug 5289 has been marked as a duplicate of this bug. ***
moving to BIOS category, since this fan issue boils down to working around a bogus BIOS _PSC.
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.
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?
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.
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.
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.
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.
Created attachment 15482 [details] dmidecode output Here is the dmidecode output.
Rui, can we check if windows uses _PSC? If not, I thought we can push the workaround.
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.
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.
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
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?
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.
Everything is working fine now.
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.
Patches already available. we can close it once the patches hit upstream.
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.
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.
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.
Hi, Lorincz Will you please confirm whether the boot option of "acpi.power_nocheck=1" is added in your test? Thanks.
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.
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.
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.
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 :)
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.
*** This bug has been marked as a duplicate of bug 11000 ***