Bug 243008

Exactly same behavior with Toshiba Satellite 14.1" Widescreen Notebook PC
(M115-S3094)

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?!

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?

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.

For what it's worth, this is still causing a problem with the latest F7 x86_64
kernel (2.6.22.5-76).

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.

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

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.

In my case, straining the CPU a bit brings the fan back to the normal.

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...

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.

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

Still not fixed in Fedora 10.

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.

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.

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.

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.

Still not fixed in Fedora 11.  It really shouldn't take over 2 years to fix this...

*** Bug 433216 has been marked as a duplicate of this bug. ***

(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.

Created attachment 347203 [details]
dmesg just before system was suspended

Created attachment 347204 [details]
dmesg just after system was resumed

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.

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.

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.

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.

You should open a new bug for separate issues.

Created attachment 348385 [details]
DSDT patch

Adds workaround code to the machine's DSDT

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.

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 :)

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.

(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.

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.

(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>)

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.

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

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.

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?

I never tried Fedora 12 but will soon, so will add comment on that issue.

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".

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)

*** Bug 538501 has been marked as a duplicate of this bug. ***

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?

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

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?

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.

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.

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.

Steve, could you install pmtools and attach the output of acpidump when run as root?

Created attachment 478072 [details]
Output of acpidump

I'm afraid I don't have a copy of Windows to verify how it behaves.

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.

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.

<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.

Yes, my bad Steve, sorry about that.