Bug 243008 - CPU fan at full speed after resume
CPU fan at full speed after resume
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: John Feeney
Fedora Extras Quality Assurance
: Reopened, Triaged
: 433216 538501 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-06 17:46 EDT by Steve Hill
Modified: 2013-01-10 01:58 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-10 10:58:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg just before system was suspended (40.15 KB, text/plain)
2009-06-10 07:31 EDT, Steve Hill
no flags Details
dmesg just after system was resumed (51.83 KB, text/plain)
2009-06-10 07:32 EDT, Steve Hill
no flags Details
DSDT patch (310 bytes, patch)
2009-06-18 03:22 EDT, Steve Hill
no flags Details | Diff
dmesg and DSDT files from Toshiba Satellite A300-24X nbook (49.72 KB, application/x-gzip)
2009-06-22 17:16 EDT, Zarko (grof)
no flags Details
Output of acpidump (142.47 KB, text/plain)
2011-02-10 10:31 EST, Steve Hill
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 13497 None None None Never

  None (edit)
Description Steve Hill 2007-06-06 17:46:29 EDT
Description of problem:
I'm running Fedora 7 on my Acer TravelMate 6413 notebook.  If I suspend to RAM
and then resume immediately everything is fine, but if I leave it suspended for
a while (over night, for example) then when it resumes the CPU fan comes on at
full speed and stays on indefinately.  Hibernating and then resuming returns the
fan to it's correct behaviour.

After a bit of Googling I have tried kicking the fan's ACPI driver by doing:
  echo -n 3 >/proc/acpi/fan/FAN0/state
  echo -n 0 >/proc/acpi/fan/FAN0/state

The first "echo" line, setting it to D3, produces an error:
  -bash: echo: write error: Exec format error

However, despite the error, dmesg shows:
  ACPI: Transitioning device [FAN0] to D3
  ACPI: Transitioning device [FAN0] to D3

No error is generated for the second "echo" line, setting it to D0, and nothing
is logged in dmesg.  In any case, it seems to have no effect on the fan's behaviour.


Version-Release number of selected component (if applicable):
pm-utils-0.99.3-6.fc7
kernel-2.6.21-1.3212.fc7

How reproducible:
Quite easy

Steps to Reproduce:
1. Suspend the machine to RAM
2. Leave it a while (maybe half a day or so)
3. Resume the machine
  
Actual results:
CPU fan comes on at full speed after the machine resumes and never turns off again

Expected results:
CPU fan should be temperature controlled (as it is before you suspend)
Comment 1 Walter Neumann 2007-07-30 01:00:34 EDT
Exactly same behavior with Toshiba Satellite 14.1" Widescreen Notebook PC
(M115-S3094)
Comment 2 Paul Osmialowski 2007-08-03 05:03:18 EDT
I've used FC3 for years on my old Toshiba Portege and the fan was temperature
controlled (as expected). After I've upgraded to F7, it is turned on all the
time.  I've checked /proc/acpi/toshiba/fan and the entry force_on was set to 0.
The only way to switch the fan off was to set it to 1 and then back to 0.
Unfortunately, I don't know if it became temperature controller since this old
laptop acts as a gateway for my network and there's not much CPU usage during
the time (and since it is in use 24/7 there's no way to run fork bomb just to
test it).
F7 worse than FC3?!
Comment 3 Paul Osmialowski 2007-08-04 13:54:29 EDT
After some hours, I've realised that when temperature rises high, fan is turned
on automatically and is never turned off. Changing force_on entry (which is 0 by
default) in /proc/acpi/toshiba/fan from 0 to 1 and then back to 0 switches fan
off, but how to cause automatic fan switch off when temperature is low enough?
Comment 4 Till Maas 2007-09-13 01:35:55 EDT
Sounds like a kernel problem rather than a pm-utils bug to me. Therefore I
changed the component from pm-utils to kernel, maybe the kernel maintainers can
help you.
Comment 5 Steve Hill 2007-09-13 04:12:08 EDT
For what it's worth, this is still causing a problem with the latest F7 x86_64
kernel (2.6.22.5-76).
Comment 6 Julian Sikorski 2007-09-27 12:03:31 EDT
I have similar problem. After resume, the following floods my /var/log/messages:

Sep 27 17:56:00 localhost kernel: ACPI: Transitioning device [FAN0] to D0
Sep 27 17:56:00 localhost kernel: ACPI: Transitioning device [FAN0] to D0
Sep 27 17:56:00 localhost kernel: ACPI: Unable to turn cooling device
[ffff81003fc426e8] 'on'

Fan seems to work fine, I guess. I have Toshiba Satellite A100-847 here,
2.6.23-0.208.rc8.git1.fc8 kernel, Fedora 7.
Comment 7 Julian Sikorski 2007-09-27 12:06:32 EDT
This happens regardless of the suspend length. Fan is off according to proc, but
it is spinning:

[jsikorski@snowball ~]$ cat /proc/acpi/fan/FAN0/state
status:                  off
Comment 8 Steve Hill 2007-11-09 14:51:16 EST
This is still happening in Fedora 8 (2.6.23.1-42.fc8 x86_64) - suspend to RAM
and when you wake up again the fan stays on at full speed.

I still haven't found a way of turning the fan off again other than hibernating
and unhibernating the machine, which seems to reset it to the correct state.
Comment 9 Julian Sikorski 2007-11-12 09:45:01 EST
In my case, straining the CPU a bit brings the fan back to the normal.
Comment 10 Christopher Brown 2008-02-03 17:01:38 EST
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

Possible CPUFreq bug so re-assinging for comments...
Comment 11 Slobodan Sredojevic 2008-08-30 19:00:31 EDT
Confirming the same behavior in Fedora 9 (2.6.25.14-108.fc9.x86_64). CPU fan is spinning at maximum speed after resume from STR. Doing suspend-to-ram/resume cycle repeatidly in both short and long intervals leave fan at max speed.
Comment 12 Bug Zapper 2008-11-26 02:18:37 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Steve Hill 2008-12-05 10:43:37 EST
Still not fixed in Fedora 10.
Comment 14 Steve Hill 2008-12-08 10:42:44 EST
Upping the severity of this bug since it effectively makes suspend rather useless (unless you want to live with a noisy fan after you resume) and no one seems to be looking at even though it has been reported by several people on different hardware.
Comment 15 Gabriel Somlo 2009-01-04 16:53:24 EST
Same behavior on MacPro1,1 tower running F10. Upon resume, the fan is pegged at
full blast, and will not return to normal unless I reboot.

Strangely, I don't have a fan showing up under /proc/acpi/fan/ either.
Comment 16 peter 2009-01-09 23:46:09 EST
I have the same problem of the fan running almost at top speed when resuming out of hibernation and suspend on a Toshiba Satellite A 105. It occurred when I used Win XP and continues to occur since I switched to Linux Ubuntu. Therefore, I do not believe this is an OS problem. I suspect it is related to the BIOS. There are no fan settings in the BIOS to address this, its a very simplistic BIOS actually.
Comment 17 peter 2009-01-11 09:47:55 EST
I looked around the Toshiba website and did not find any solutions or info on this problem. I will attempt a direct email inquiry and see if they respond. I'll post any response here.
Comment 18 Steve Hill 2009-06-10 03:54:54 EDT
Still not fixed in Fedora 11.  It really shouldn't take over 2 years to fix this...
Comment 19 Christopher Brown 2009-06-10 04:31:08 EDT
*** Bug 433216 has been marked as a duplicate of this bug. ***
Comment 20 Christopher Brown 2009-06-10 04:37:27 EDT
(In reply to comment #18)
> Still not fixed in Fedora 11.  It really shouldn't take over 2 years to fix
> this...  

Agreed. Though it would be interesting to know if you're running the latest BIOS and have played with any fan settings in it as this might sort the problem in itself. If not, I recommend attaching the contents of dmesg (prior to and after resume) to this bug as this might help move things along.
Comment 21 Steve Hill 2009-06-10 07:31:48 EDT
Created attachment 347203 [details]
dmesg just before system was suspended
Comment 22 Steve Hill 2009-06-10 07:32:18 EDT
Created attachment 347204 [details]
dmesg just after system was resumed
Comment 23 Steve Hill 2009-06-10 07:34:57 EDT
Just updated to the latest BIOS (3.04) - no change.  There are no fan settings in the BIOS.

I've added the requested attachments, also opened a bug on kernel.org: http://bugzilla.kernel.org/show_bug.cgi?id=13497

Some further debugging: this only seems to affect the system if it is suspended for around 3 minutes or more - this leads me to believe it is a timeout somewhere.
Comment 24 How 2009-06-17 07:04:55 EDT
cant believe this problem dragged on for so many versions. 
Fedora 11 still doesnt work here. The fan is full speed when Xserver starts and whenever you login the fan keeps going for long time.
Comment 25 Steve Hill 2009-06-17 07:30:54 EDT
It doesn't sound like your problem is the same one - this issue strictly affects resuming from the ACPI S3 state.  See the kernel.org bug for details - it is a bug in the machine's DSDT.  There is a workaround, but some resistance to incorporating it into the kernel.
Comment 26 How 2009-06-17 18:45:41 EDT
It might not be the same, but I resume from hibernate and suspend cpu fan full speed and is to do with laptop. Didnt happen in Opensuse 11.0, only when I just installed FC11.
Comment 27 Steve Hill 2009-06-18 03:21:48 EDT
You should open a new bug for separate issues.
Comment 28 Steve Hill 2009-06-18 03:22:38 EDT
Created attachment 348385 [details]
DSDT patch

Adds workaround code to the machine's DSDT
Comment 29 Zarko (grof) 2009-06-22 17:02:53 EDT
Hello

I have the same problem on my Toshiba Satellite A300 and Fedora 11.
I can not apply the patch because my DSDT file isn't the same as patche's.
The Fan running constantly after resume.

I will prepare my full DSDT file and I'll attach here.
Comment 30 Zarko (grof) 2009-06-22 17:16:17 EDT
Created attachment 348999 [details]
dmesg and DSDT files from Toshiba Satellite A300-24X nbook

Here is my dmseg before and after resume from suspend to RAM state, and DSDT.dsl file.

Any suggestion is welcome :)
Comment 31 Joey Bell 2009-07-18 04:48:31 EDT
Hi, I also encounter the fan-after-resume problem. But I have a TYAN server motherboard. I wonder what is(n't) happening compared to restoring from hibernate, but I am not knowledgable enough about Linux internals to find out.
Comment 32 Joey Bell 2009-07-21 06:18:50 EDT
(In reply to comment #31)
> Hi, I also encounter the fan-after-resume problem. But I have a TYAN server
> motherboard. I wonder what is(n't) happening compared to restoring from
> hibernate, but I am not knowledgable enough about Linux internals to find out.  

This bug really affects me: this morning I came out of hibernate (like everyday) and the machine takes about 4 mins to load, the interaction with the computer is slow for the next 20 mins, and everything is in swap so I have to wait everytime I move to a different part of a program.

I was very happy with the 20-second Fedora startup, but my more usual scenario is to use suspend or hibernate. With the fan problem this is an on-going pain.
Comment 33 Joey Bell 2009-07-28 14:56:52 EDT
OK, for any of you who are still using Fedora, here's a way to solve the problem: follow the steps on this website (http://tuxtweaks.com/2008/08/how-to-control-fan-speeds-in-ubuntu/) although ignore the first apt-get command, and the last one.

There will be a few times where pwmconfig tries fans that turn out not to be there/accessible. Also, when running pwmconfig, you must configure your fans after the tests to be able to run fancontrol. You will be able to deduce sensible settings from the labels on the fans/monitors.

If you want to monitor your temperatures to ensure you don't overheat while finding a good configuration, you can easily install KSensors with the package manager, and configure it to show the temperature in the GNOME tray.

After initial set-up you will have to load it at start-up. There is a how-to link on the page.

OK, F11 is back to being the best Linux dist I've tried.
Comment 34 Steve Hill 2009-07-28 15:07:10 EDT
(In reply to comment #33)
> OK, for any of you who are still using Fedora, here's a way to solve the
> problem: follow the steps on this website
> (http://tuxtweaks.com/2008/08/how-to-control-fan-speeds-in-ubuntu/) although
> ignore the first apt-get command, and the last one.

Sorry, this comment is not applicable to this bug - it will not fix the problem.  The fix is to apply the DSDT patch I already uploaded.  Unfortunately it isn't a good fix since it involves rebuilding the kernel each time it is updated.

Anyway, it looks like Acer aren't going to fix this - they have stopped responding to my emails.  I did email the DSDT patch to them but I very much doubt they care.  (Full email chain at http://www.nexusuk.org/~steve/acer.xhtml </rant>)
Comment 35 Matthew Garrett 2009-07-28 15:09:38 EDT
Note that on many systems following the above instructions will interfere with the BIOS's control of the fan, and as a result you risk data loss or (possible but unlikely) hardware damage.
Comment 36 Dennis Wagelaar 2009-09-28 08:46:49 EDT
This problem no longer occurs on my MSI G965MDH mainboard since I've updated to the latest BIOS (v.3.5):

http://www.msi.com/index.php?func=downloaddetail&type=bios&maincat_no=1&prod_no=1122
Comment 37 Nick Turenkov 2009-11-04 02:44:29 EST
That bug still valid for me. I have all latest updates for my fedora 11, and after suspend mode my cpu fan speed is very high. I'm using HP 6730s laptop with last BIOS installed. Kernel Linux 2.6.30.9-90.fc11.x86_64. Processor: Intel Core 2 Duo T5670 1.8 GHz. I'm not an expert with linux so I do not know which debug info needed to solve that problem. But if somebody can explain me, I can share additional logs or something.
Comment 38 Vedran Miletić 2009-11-12 11:36:01 EST
I have this in Fedora 12 on HP 6710s. But, unlike for most folks here, this was not an issue with Fedora 11, at least back in October (when I upgraded to Rawhide).

Nick, do you have the same issue with Fedora 12?
Comment 39 Nick Turenkov 2009-11-18 02:47:05 EST
I never tried Fedora 12 but will soon, so will add comment on that issue.
Comment 40 Nick Turenkov 2009-11-25 13:18:42 EST
Ok, I just installed Fedora 12 with kernel 2.6.31.5-127 x86_64 on HP 6730s and CAN'T reproduce this bug with latest updates and BIOS. Only one hack made to launch that kernel on my machine "intel_iommu=off".
Comment 41 Nick Turenkov 2009-11-27 05:41:10 EST
Now it is still an issue for me. But I saw that after ~1 minute my CPU fan reduced his speed. (Tested on Fedora 12 with latest updates)
Comment 42 James M. Leddy 2010-01-06 12:38:53 EST
*** Bug 538501 has been marked as a duplicate of this bug. ***
Comment 43 Steve Hill 2010-07-28 11:42:30 EDT
This is still a problem, but can be worked around without recompiling the kernel now - recent kernels allow runtime patching of single DSDT methods from userland, so I've implemented the workaround here: http://subversion.nexusuk.org/projects/acer_dsdt/trunk/

I'm unclear on what Fedora's policy is regarding the implementation of workarounds for firmware bugs in cases where the hardware vendor is never going to fix them - can this fix be included in Fedora?
Comment 44 Bug Zapper 2010-11-04 08:10:16 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 45 Steve Hill 2010-11-04 08:19:06 EDT
Still a problem in Fedora 13.

This bug was reported 7 releases ago *AND A FIX HAS BEEN ATTACHED TO THIS TICKET*, so why is it still unfixed?
Comment 46 Matthew Garrett 2011-02-09 11:56:24 EST
Closing this because it's a huge mess of people with different problems on different hardware. If people still see this issue, please open one bug per affected machine.
Comment 47 Steve Hill 2011-02-10 06:58:29 EST
Reopening because the original problem is still present in Fedora 14, 3.5 years after the bug was opened, even though a workaround has been provided in this ticket, and there isn't a lot I can do to stop people inappropriately jumping on a bugzilla ticket and filing unrelated bugs.

SUMMARY:
On an Acer TravelMate 6413 notebook.  If I suspend to RAM and then resume immediately everything is fine, but if I leave it suspended for a while (over night, for example) then when it resumes the CPU fan comes on at full speed and stays on indefinately.  Hibernating and then resuming returns the fan to it's correct behaviour.

WORKAROUND:
A DSDT patch is here: http://subversion.nexusuk.org/projects/acer_dsdt/trunk/

GOTCHA:
On Fedora 14 the acpi directory in the debugfs no longer exists so you can't easily patch the DSDT any more - ARGH!.

NOTES:
The upstream Kernel bug was closed with basically "we don't need to patch this because the end users can hack up their own DSDT" which isn't really satisfactory (how many end-users know enough to write and apply a DSDT patch?).  AFAIK the kernel policy is usually to make Linux work despite hardware/firmare bugs where possible and this seems to be at odds with the policy.  Unfortunately, when I asked for clarification my question was ignored.  So to raise the question again: What *IS* the policy on patching broken DSDTs (and other firmwares)?  Is it reasonable for the Kernel or an init script of specific Linux distributions to automagically patch busted firmare on boot?  It is clear that the vendor doesn't care (they have been informed of the problem and have even been sent the DSDT patch but haven't reacted), so placing responsibility on them is unhelpful.
Comment 48 Matthew Garrett 2011-02-10 08:50:18 EST
We don't patch DSDTs and we won't patch DSDTs. There's no way to do so reliably. If Windows doesn't behave the same way then we will attempt to identify why the same bug is not visible on Windows and will modify Linux to match.
Comment 49 Matthew Garrett 2011-02-10 10:02:12 EST
Steve, could you install pmtools and attach the output of acpidump when run as root?
Comment 50 Steve Hill 2011-02-10 10:31:30 EST
Created attachment 478072 [details]
Output of acpidump
Comment 51 Steve Hill 2011-02-10 10:33:14 EST
I'm afraid I don't have a copy of Windows to verify how it behaves.
Comment 52 Matthew Garrett 2011-02-10 10:58:57 EST
There's no code path that triggers the same SMM trap, and it turns out that all the fan control methods are just stubs that don't do anything. So it seems that the fan is effectively entirely under the firmware's control and we have no influence over it. Unless this doesn't happen under other operating systems (and the kernel bugzilla entry suggests that it does) then I'm afraid that your BIOS or EC firmware or simply broken. We can't add infrastructure to add code to BIOSes because there's no good reliable mechanism to verify that we'll only do so on the correct machines, and adding calls to system management mode (ie, code that is literally impossible for us to get at) is an excellent way for us to cause hardware damage if we get it wrong. There's really just nothing we can do to make this machine work.
Comment 53 Christopher Svanefalk 2011-10-26 02:37:17 EDT
I know it is closed, but just wanted to note that this is still present as of F16 Beta, running Gnome 3.2 (it does NOT happen when running LXDE for some reason).

I am on an HP Probook 4510s.
Comment 54 Steve Hill 2011-10-26 05:40:48 EDT
<sigh> This report has been completely overrun by inappropriate comments like the above one.

Please read the whole report before adding a "me to" - this report specifically relates to the Acer Travelmate 6410 series laptops.  It is due to a firmware bug in that device and is fixable with a DSDT patch, but unfortunately Acer have refused to acknowledge or fix the bug even though they have been given the patch.

If you are not using Acer hardware, the bug you are seeing is almost certainly not the same one as in this report and you should do some debugging and figure out what is causing it in your case, then open a new bug report for your specific problem.
Comment 55 Christopher Svanefalk 2011-10-26 08:15:58 EDT
Yes, my bad Steve, sorry about that.

Note You need to log in before you can comment on or make changes to this bug.