Ubuntu

Laptop Fan always on after resume from suspend to RAM

Reported by Julien64 on 2006-12-28
168
This bug affects 29 people
Affects Status Importance Assigned to Milestone
acpi (Ubuntu)
Undecided
Unassigned
Declined for Karmic by Sebastien Bacher
Declined for Lucid by Sebastien Bacher
Declined for Maverick by Sebastien Bacher
linux (Ubuntu)
Medium
Unassigned
Declined for Karmic by Sebastien Bacher
Declined for Lucid by Sebastien Bacher
Declined for Maverick by Sebastien Bacher
linux-source-2.6.17 (Ubuntu)
Undecided
Unassigned
Declined for Karmic by Sebastien Bacher
Declined for Lucid by Sebastien Bacher
Declined for Maverick by Sebastien Bacher

Bug Description

Binary package hint: initramfs-tools

After doing a suspend to RAM, the fan is always "on" on my laptop, even if temperatures are low (where the fan would normally be off before going to sleep mode for the first time).
I removed the /usr/share/initramfs-tools/hooks/thermal script and now everything works fine (fan behaviour is not anymore affected by the suspend to RAM). It seems like this script does a wrong initialization of something which is not needed on my PC.
My laptop is a Toshiba satellite A100-308 with dual core centrino. I have a basic standard ACPI support, toshiba_acpi and omnibook kernel modules do not work with my hardware.

Julien64 (julien-jls-info) wrote :

I am using ubuntu 6.10 with initramfs-tools 0.69ubuntu20.0

Julien64 (julien-jls-info) wrote :

It seems to be more a kernel problem... Once I heat up my CPU up to 52 degC, the fan works normally again. My proposed initial patch on initramfs-tools does not work all the time.

David Stone (superdav42) wrote :

I have the same problem with my Dell Latitude 100L. The fan stays on after suspend at about half the max speed. If I put a heavy load on the system the fan will go to high speed and once I stop the load the fan will stop complete and act like it usually would.

Thanks for taking the time to report this bug. Unfortunately we can't fix it, because your description didn't include enough information.

Please include the information requested from https://wiki.ubuntu.com/DebuggingACPI as separate attachments.

Change Status of Unconfirmed to Needs Info.

Changed in linux-source-2.6.17:
status: Unconfirmed → Needs Info
Brian Murray (brian-murray) wrote :

We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and feel free to submit bug reports in the future.

Changed in linux-source-2.6.17:
assignee: nobody → brian-murray
status: Needs Info → Rejected
David Stone (superdav42) wrote :

I just did a clean install of 8.04 and still get the same problem. I will attach all the requested files for you to look at.
Once again I am using a Dell latitude 100L.

David Stone (superdav42) wrote :

output of dmidecode

David Stone (superdav42) wrote :

Output of lspci

David Stone (superdav42) wrote :

output of uname -a

Changed in linux-source-2.6.17:
status: Invalid → New
Changed in linux-source-2.6.17:
assignee: brian-murray → nobody
status: New → Won't Fix
Changed in linux:
assignee: nobody → ubuntu-kernel-acpi
importance: Undecided → Medium
status: New → Confirmed
Changed in linux:
status: Confirmed → Triaged

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Jesse (sbjesse) wrote :

I'm also seeing this problem on my Compaq cq20 running Hardy 32bit. There's this strange thermal zone censor called "FDTZ" that's reporting a 93 Celsius temperature after resume from suspend. And I'm almost sure it's not as hot as it reports. Coz it was around 40 degrees before suspend.

To Leann: how can i install the 2.6.27 kernel in hardy? I can't find this package in the deb repo

Jesse (sbjesse) wrote :

attaching all files mentioned in the wiki page.
i'm sure that thermal zone is not reporting the right temperature now. before suspend it was reporting (constantly) 30 degrees, and it always reports 93 after resume. Vista doesn't have this problem.

Jesse (sbjesse) wrote :

I'm experiencing this on Intrepid with the newly updated kernel 2.6.27-10. This was previously fixed in 2.6.27-7, so I guess this is a regression...

Tim Wiel (timwiel) wrote :

I can confirm this is an issue on a HP 6730b laptop running new linux kernel 2.6.7-10 from intrepid-proposed. Suspending to RAM again and resuming seems to fix the issue.

However sometimes the issue only occurs every four resumes rather than every second resume

Mahmoud ElGammal (gammal) wrote :

This also happen on my machine, but not just after resume. I believe that once the fan is turned on it's never turned off again, even if the machine is under very light load. My machine is a Toshiba Satellite L305-S5899 with InsydeH2O BIOS, and I'm using 8.10 with kernel 2.6.27-11-generic. It's also worth mentioning that toshset gives me this error "required kernel toshiba support not enabled."

TJ (tj) wrote :

According to Hewlett Packard information, the ACPI FDTZ is actually the *Fan Speed* as a percentage of maximum speed. This would explain why Jesse is seeing high FDTZ values on resume coupled with fan noise.

I'd like to inspect the ACPI DSDT of the affected models. I've created a shell script (pack-dsdt) to automate the collection process and attached it to this bug report. Download it to the affected PC, make the script executable, and run it:

 chmod a+x pack-dsdt
 sudo ./pack-dsdt

The end-result will be a tar.gz archive in /tmp/ that can be attached to this bug report.

Jesse (sbjesse) wrote :

Dear TJ,
  Should I boot into the offending kernel? I mean the 2.6.27-7-generic kernel works fine for me so far, but the ones upgraded later (e.g.2.6.27-12) actually will drive up the fan.
  Thanks a lot

Jesse

On Sun, 2009-03-01 at 13:57 +0000, Jesse wrote:

> Should I boot into the offending kernel? I mean the 2.6.27-7-generic kernel works fine for me so far, but the ones upgraded later (e.g.2.6.27-12) actually will drive up the fan.

No, use the 'good' kernel since the script is going to collect
information about the BIOS and we don't want things to go wrong.

Jesse (sbjesse) wrote :

@TJ I'm attaching the DSDT report you asked for

Jesse (sbjesse) wrote :

@TJ your script doesn't expect Model names to have special characters, I've patched it with extra quotes. see attachment

pawel (maijstral) wrote :

i've hp compaq 6735b with ubuntu 8.10
I've made some modification to scrpit /etc/acpi/resume.d/72-acpi-pain.sh
i've moved "NNGH FAN HATE" part to the end of script, after modules loading.
after few sleep/wake up test rounds i think it works.

Jesse (sbjesse) wrote :

@pawel thanks for your tips.
But it doesn't seem to work for me. Now after waking up from STR, my fan is high up again
$ uname -r
2.6.27-14-generic
$ cat /proc/acpi/fan/*/state
status: off
status: off
status: off
status: off
status: on

After a few trials, it seems to me that the argument "3" turns off the corresponding fan while "0" turns them on.
It turns out the naughty fan is FAN0, not FAN4.
$ echo 0 | sudo tee /proc/acpi/fan/FAN0/state
0
And then the noise vanished.
I wonder if my FAN4 is nonexistent, coz having it on doesn't yield much noise...

The script in resume.d seems to be just doing the opposite: upon resuming, it turns each fan on right after turning them off.
The effect is funny though, contrary to its intension, only FAN4 remains "on" when I inspect the fan states.

Anyone give some pointers or shed more lights on this?

Jesse (sbjesse) wrote :

sorry I meant to say
$ echo 3 | sudo tee /proc/acpi/fan/FAN0/state
in the previous post

voneiden (snaipperi) wrote :

Running HP 6735s,
$ uname -r
2.6.28-11-generic

I have the same problem with suspending, ie fan runs at fast speed with no control over it. After a clean restart, though, when everything is working "fine", there is one oddity:

$ cat /proc/acpi/thermal_zone/CPUZ/*
<setting not supported>
<polling disabled>
state: ok
temperature: 44 C
critical (S5): 105 C
passive: 100 C: tc1=1 tc2=2 tsp=100 devices=CPU0 CPU1
active[0]: 85 C: devices=FAN0
active[1]: 70 C: devices=FAN1
active[2]: 62 C: devices=FAN2
active[3]: 50 C: devices=FAN3

$ cat /proc/acpi/fan/*/state
status: off
status: off
status: off
status: off

Before reaching the first trip point everything's as supposed. When temp reaches 50, FAN3 turns on:
$ cat /proc/acpi/fan/FAN3/state
status: on

however dmesg shows an error:
[ 2689.560949] ACPI: Transitioning device [FAN3] to D0
[ 2689.560956] ACPI: Unable to turn cooling device [f6c1dca8] 'on'
[ 2689.566424] ACPI: Transitioning device [FAN3] to D0
[ 2689.566429] ACPI: Unable to turn cooling device [f6c1dca8] 'on'

and the thermal_zone state is still OK (afaik it should be active[3]?)
$ cat /proc/acpi/thermal_zone/CPUZ/state
state: ok

No error appears in dmesg after the temp cools down below the new state 3 trip point (45C) and the fans turn off. So if ACPI is unable to control the device, then what is..? And is this related to the suspend problem?

Jesse (sbjesse) wrote :

Now I have a fresh installation of Jaunty, and the problem persists. After resuming from STR, I get the exact same symptom as under Intrepid newer kernels: FAN0 is reported to be in "off" state, while FAN4 says "on". Turning on and then off (with 1 second in between) FAN0 quiets the machine.
Hope this report helps

Hardware: Compaq Presario CQ20; uname -r: 2.6.28-11-generic

voneiden (snaipperi) wrote :

In my case, should I echo the fan states off and back on, the fan[i]'s turn on according to the current trip points. For example, having active[2] 62 C, and the computer temperature at the time of issuing the echo would be 65, FAN3 (50C) and FAN2 (62C) are set on. FAN1 and FAN0 stay off regardless of the command.

The ACPI event system seems to be totally dead after STR (acpi_listen gives no thermal etc. events any more), so the fans will not turn off without manual re-echo of "off and on" OR without enabling polling!

However, even with the polling enabled nothing is adjusting the trip points, resulting in a fan turning constantly on and off as the temperature bounces +-2C around the default trip point.

Doing as Jesse suggested is not an option at least for me, as the fan does not react to temperature changes it might result in serious overheating (what if critical temperature event is not received?).

Having only FAN3 (or FAN4 in Jesse's case?) on is the slowest spinning speed of the fan. This is enough to keep the system cool on light load but no more.

vasek125 (vasek) wrote :

I fixed this problem in my hp 6730b by creating /etc/pm/sleep.d/99funguj.

#!/bin/sh
#
# 99funguj: sprav co se da

case "$1" in
        hibernate|suspend)
                # Stopping is not required.
                ;;
        thaw|resume)
                # sprav to
                for x in /proc/acpi/fan/*; do
                    if [ -f "$x/state" ] && [ "`grep on $x/state`" ]; then
                        echo -n 3 > $x/state;
                        echo -n 0 > $x/state;
                    fi
                done
                for x in /proc/acpi/fan/*; do
                    if [ -f "$x/state" ] && [ "`grep off $x/state`" ]; then
                        echo -n 0 > $x/state;
                        echo -n 3 > $x/state;
                    fi
                done
                ;;
        *) exit $NA
                ;;
esac

I found that rewriting values in state files fix this problem. But ubuntu uses pm-utils so /etc/acpi/resume.d/72-acpi-pain.sh does not run.

vasek125 (vasek) wrote :

correction: sleep interval is needed between "echo -n xxxx"

Hao Zhe XU (haozhe.xu3) wrote :

vasek125: so can you tell me where do I put the script, in /etc/pm/sleep.d ?
also, what is the syntax for sleep interval? What interval is needed? Is it like:

echo -n 3 > $x/state;
sleep 2000
echo -n 0 > $x/state;

is 2000 msec or sec?

Thanks!

vasek125 (vasek) wrote :

Just try what is sufficient. I have sleep 1. Sleep interval is in seconds. To speed up the resume write something like:

                for x in /proc/acpi/fan/*; do
                    if [ -f "$x/state" ] && [ "`grep off $x/state`" ]; then
                        echo "echo -n 0 > $x/state;" >> /tmp/fanstate0
                        echo "echo -n 3 > $x/state;" >> /tmp/fanstate3
                    fi
                done
  sh /tmp/fanstate0
  sleep 1
  sh /tmp/fanstate3

  rm /tmp/fanstate0
  rm /tmp/fanstate3

Hao Zhe XU (haozhe.xu3) wrote :

Thanks vasek125 for your reply, but I am a noob, where do I replace in the original script with your new piece of code? Sorry for my problem.

vasek125 (vasek) wrote :

This is new code:

#!/bin/sh
#
# 99funguj: sprav co se da

case "$1" in
 hibernate|suspend)
  # Stopping is not required.
  ;;
 thaw|resume)
  # sprav to
  for x in /proc/acpi/fan/*; do
      if [ -f "$x/state" ] && [ "`grep on $x/state`" ]; then
          echo -n 3 > $x/state;
          echo -n 0 > $x/state;
      fi
  done
                for x in /proc/acpi/fan/*; do
                    if [ -f "$x/state" ] && [ "`grep off $x/state`" ]; then
                        echo "echo -n 0 > $x/state;" >> /tmp/fanstate0
                        echo "echo -n 3 > $x/state;" >> /tmp/fanstate3
                    fi
                done
  sh /tmp/fanstate0
  sleep 1
  sh /tmp/fanstate3

  rm /tmp/fanstate0
  rm /tmp/fanstate3
  ;;
 *) exit $NA
  ;;
esac

olbrait (milan-olbert) wrote :

nazdar vasek125

In my case it didn't work. I created that document (the last one) in ...pm/sleep.d/ , but after resume from suspend fans are once again always on

jaunty jackalope, 64 bit, upgraded from Beta

olbrait (milan-olbert) wrote :

ok, it seems that it's work. But after resume the fans are off until temperature appears to 90 C (trip_points are 45:62:70:85), after that is activated fan0state (everythings "on"). Then it works normal. Fans are getting "off" with downgrading temperature and "on" with his increasing. So, it's work :)

good job vasek

olbrait (milan-olbert) wrote :

for everyone with same problem, don't forget to make "99funguj" executeable, as in my case

Ingo Karkat (inkarkat) wrote :

Thank you for posting this script, vasek125. It also works on a HP Compaq 6735s running Ubuntu 9.04. I had previously resorted to a more complex workaround which involved heating the CPU to reach the next trip point (Cp. Ubuntu bug #343128: Noisy fan after resume on HP 6735s at https://bugs.launchpad.net/bugs/343128), but that now doesn't seem necessary.
However, since due to the bug in the HP 6735s no ACPI events are sent any more after resume from standby, I also had to enable polling via
echo -n 5 > /proc/acpi/thermal_zone/CPUZ/polling_frequency
Without this, the CPU fan would keep off / spinning at the lowest speed even when the CPU temperature gets very high.

You can test whether your notebook is affected by running a CPU-intensive command (like burnK7 from the 'cpuburn' package, or a simple 'while true; do true; done' loop) and observing whether the fan increases speed when the CPU temperature (cat /proc/acpi/thermal_zone/CPUZ/temperature) reaches the next trip point (cat /proc/acpi/thermal_zone/CPUZ/trip_points). If not, append the above command to enable polling to the 99funguj script (e.g. after the 'rm /tmp/fanstate3' line), like I did.

vasek125 (vasek) wrote :

Everything is working fine with this script on my HP 6730b. Laptop is not overheating, fan speed regulation works great. Everything works well.

voneiden (snaipperi) wrote :

Ingo,

The trip points are also set on different values after resume than upon system boot. Also the trip points are not modified upon reaching trip points through polling. The problem then is increased fan speeds (the trip points provided are lower after resume than upon bootup) and fan speeding or slowing at every poll in certain cpu usage conditions.

I recall trying to update the trip points through a script but failed somewhere along.

olbrait (milan-olbert) wrote :

good job Ingo Karkat

echo -n 5 > /proc/acpi/thermal_zone/CPUZ/polling_frequency

and everything works perfect

HP 6735s Jaunty Jackalope 64bit

23 comments hidden view all 103 comments
123vier (flowrist) wrote :

confirmed on lenovo ideapad Z350 @ 2.6.32-24-generic #39-Ubuntu SMP

unplugging and replugging doesn't help

Changed in linux (Ubuntu):
assignee: Ubuntu Kernel ACPI Team (ubuntu-kernel-acpi) → nobody

I had this problem too on my Lenovo Ideapad z360 and kernel 2.6.32-24-generic. After upgrade to 2.6.35 (downloaded from kernel ppa) it seems to work fine.

 2.6.35-02063505-generic #201009211107 SMP Tue Sep 21 11:09:35 UTC 2010 x86_64 GNU/Linux

123vier (flowrist) wrote :

Thanks, will try it asap.
But does this also absolve the display-brightness problem?

Since I use the ppa of kamal mostafa (i915 patched kernel) to prolong battery life by dimming the display I'm very hesitant to upgrading.

ps: Of course I'm also running the z360 model. My original comment contained a typo.

2010/9/23 Simone Schäfer <email address hidden>

    I had this problem too on my Lenovo Ideapad z360 and kernel
    2.6.32-24-generic. After upgrade to 2.6.35 (downloaded from kernel ppa)
    it seems to work fine.

     2.6.35-02063505-generic #201009211107 SMP Tue Sep 21 11:09:35 UTC 2010
    x86_64 GNU/Linux

    --
    Laptop Fan always on after resume from suspend to RAM
    https://bugs.launchpad.net/bugs/77370
    You received this bug notification because you are a direct subscriber
    of the bug.

--
GRATIS: Spider-Man 1-3 sowie 300 weitere Videos!
Jetzt freischalten! http://portal.gmx.net/de/go/maxdome

No, unfortunately the display-brightness problem still remains - at least I didn't manage to make it work.

cherep (acherep) wrote :

I have a little bit different problem with the fan speed. When I start Ubuntu first time (maybe the reason is that the system is cold), my fan is going crazy. After rebooting two or even three times everything is going well.

The display-brightness problem influences me deeply as well!!!

Using 10.10 on Lenovo z360.

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: Triaged → Won't Fix
Changed in acpi (Ubuntu):
status: New → Confirmed
Timothy Mayoh (timothy-m) wrote :

This apparently still affects Ubuntu 11.04, with HP 4310s laptops, according to bug #818771.

shadow (arnyek) wrote :

More information:
Before suspend (AC power plugged in):
$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +16.0°C (crit = +108.0°C)
temp2: +39.0°C (crit = +105.0°C)
temp3: +42.0°C (crit = +108.0°C)
temp4: +43.0°C (crit = +105.0°C)
temp5: +36.8°C (crit = +108.0°C)
temp6: +40.0°C (crit = +110.0°C)
Suspend...
10 second later wake up (power button). temp6 = +49.0°C. Fan is ok, not always on!
Try again.
Suspend...
2 minutes later wake up (power button). temp6 = +90.0°C. Fan is always on.
Plug off AC power for 1s, then plug in again: temp6 step by step go back 40°C and fan go back normal speed.
(Sorry for my bad english)

shadow (arnyek) wrote :

I have disabled "Fan always on while on AC power" in BIOS, and everything works fine!
Ubuntu 11.04, HP 4310s laptops.

shadow (arnyek) wrote :

Are there any news?
I tried Ubuntu 11.10 Beta2, and this bug still there too.
I can't use suspend, I feel like living in early 90s...
I have not /proc/acpi/fan that's why not working me any workaround script.
Very fustrating...

piotrekf (piotrekf) wrote :

I'm not using Ubuntu at the moment, but i think it's relevant.
On recent kernels there is no /proc/acpi/fan or /proc/acpi/thermal. Instead there are /sys/devices/virtual/thermal/cooling_deviceX and /sys/devices/virtual/thermal/thermal_zoneX, or something like that. I didn't managed to get workaround scripts working, but:
rmmod thermal;
modprobe thermal tzp=1000; (or other numer, tzp - Thermal Zone Polling frequency, units are in deci-seconds)
sometimes running above commands fix it for me, but then again, sometimes it don't...

shadow (arnyek) wrote :

Thank yout piotrekf! You help me a lot!

I'ts work for me:
echo -n "1" > /sys/devices/virtual/thermal/cooling_device11/cur_state
sleep 10
echo -n "0" > /sys/devices/virtual/thermal/cooling_device11/cur_state

Same problem occurs to me since I upgraded to 11.10. To clarify:

The problem did NOT occur with:
- linux-image-2.6.35-28-generic

The problem does occur with:
- linux-image-2.6.38-11-generic
- linux-image-2.6.38-12-generic
- linux-image-3.0.0-12-generic
- linux-image-3.0.0-13-generic

Is there any workaround to manually switch off the fan? Given the current bug I must restart the computer.

shadow (arnyek) wrote :

Iñaki Baz Castillo:
I'ts work for me: #76

#76 is the response:

- echo -n "1" > /sys/devices/virtual/thermal/cooling_device11/cur_state

That stops the fan.

Frank Lazzarini (flazzarini) wrote :

I have the same problem on my HP 620 Laptop @ work, and I have a rather simple fix for this :) ! Unplug the power cable and replug the power cable! Sounds stupid I know but it works :P

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 11.10
Release: 11.10
Codename: oneiric

# uname -a
Linux pc-frank 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Fabrizio F (f-forzano) wrote :

Combining all previous posts, i made this file /etc/pm/sleep.d/99fancontrol.sh that worked perfectly for me:

--------------------------------------
#!/bin/sh
#
# Blocca le ventole.
# ripreso da: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/77370

case "$1" in
 hibernate|suspend)
  # Stopping is not required.
  ;;
 thaw|resume)
# In background.
   ( sleep 10 ; echo -n "0" > /sys/devices/virtual/thermal/cooling_device1/cur_state ) &

  ;;
 *) exit $NA
  ;;
esac

--------------------------------------

I'm using a laptop HP6735S, with ubuntu maverick:

uname -a
Linux gaviota-maverick 2.6.35-30-generic #61-Ubuntu SMP Tue Oct 11 15:29:15 UTC 2011 i686 GNU/Linux

PS: remember to chmod 755 the newly created file

Ricardo Bocaz L. (rbocazl) wrote :

This worked for me. HP420 running openSUSE. Thanks a lot!!!!

Fabrizio F (f-forzano) wrote on 2011-11-17: #82

Combining all previous posts, i made this file /etc/pm/sleep.d/99fancontrol.sh that worked perfectly for me:

--------------------------------------
#!/bin/sh
#
# Blocca le ventole.
# ripreso da: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/77370

case "$1" in
 hibernate|suspend)
  # Stopping is not required.
  ;;
 thaw|resume)
# In background.
   ( sleep 10 ; echo -n "0" > /sys/devices/virtual/thermal/cooling_device1/cur_state ) &

  ;;
 *) exit $NA
  ;;
esac

--------------------------------------

I'm using a laptop HP6735S, with ubuntu maverick:

uname -a
Linux gaviota-maverick 2.6.35-30-generic #61-Ubuntu SMP Tue Oct 11 15:29:15 UTC 2011 i686 GNU/Linux

PS: remember to chmod 755 the newly created file

on my HP ProBook 5310m this one helps:

#!/bin/sh
#
# https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/77370

case "$1" in
 hibernate|suspend)
  # Stopping is not required.
  ;;
 thaw|resume)
# In background.
 file="/sys/bus/acpi/drivers/fan/PNP0C0B\:00/thermal_cooling/cur_state"
   ( sleep 5 ; echo 1 >file ; echo 0 >file ) &

  ;;
 *) exit $NA
  ;;
esac

Petteri P (petterip) wrote :

I have the same proble on my HP Envy 2090 and I can't get it fixed and don't really know where to even start.

I have tried fiddling with the above (82, 83 and 84) tricks, but I get a file permissions error:
petteri@ENVY14:~$ echo -n 1 > /sys/devices/virtual/thermal/cooling_device0/cur_state
bash: /sys/devices/virtual/thermal/cooling_device0/cur_state: Permission denied

Is there something I need to change before I set the value for cur_state? The directories and files seem to be write protected.

uname -a
Linux ENVY14 3.2.0-24-generic #38-Ubuntu SMP Tue May 1 16:18:50 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

shadow (arnyek) wrote :

 #85

You need to be root:

user@host:~$ sudo -i
user@host:~# echo -n 1 > /sys/devices/virtual/thermal/cooling_device0/cur_state

Petteri P (petterip) wrote :

#86 Thanks. I thought just sudoing the command was enough.

Alas, still no luck in turning off the fan after suspend. I tried few combinations of these commands:
echo -n "0" > /sys/devices/virtual/thermal/cooling_device0/cur_state
echo -n "0" > /sys/bus/acpi/drivers/fan/PNP0C0B\:00/thermal_cooling/cur_state

, but they seem to have no effect on the fan. I tried the script in #82 as well without success.

After resuming from suspend the sensors command shows clearly that one temperature is high, although it really is not, and that fires the fan I guess:
root@ENVY14:~# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +47.0°C (crit = +120.0°C)
temp2: +89.0°C (crit = +127.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +49.0°C (high = +86.0°C, crit = +100.0°C)
Core 0: +49.0°C (high = +86.0°C, crit = +100.0°C)
Core 1: +50.0°C (high = +86.0°C, crit = +100.0°C)
Core 2: +47.0°C (high = +86.0°C, crit = +100.0°C)
Core 3: +47.0°C (high = +86.0°C, crit = +100.0°C)

Before a suspend the temp2 shows usually a value similar to temp1. Does someone have suggestions what I could research next?

Vladimir (mishnov) wrote :

For my HP ProBook 5310m has helped the following:
Create the file ”/etc/pm/sleep.d/99fancontrol.sh”, insert the code below and chmod 755 it.

Script:
#!/bin/sh
#
# https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/77370

case "$1" in
 hibernate|suspend)
  # Stopping is not required.
  ;;
 thaw|resume)
# In background.
    echo -n 1 > /sys/devices/virtual/thermal/cooling_device0/cur_state;
    sleep 2
    echo -n "0" > /sys/bus/acpi/drivers/fan/PNP0C0B\:00/thermal_cooling/cur_state;

  ;;
 *) exit $NA
  ;;
esac

Petteri P (petterip) wrote :

Thanks, but I have tried this and some variants on this thread.

It seems to me that the cur_status of cooling_device0 just does not change. Every other one has status 0 and I can change them, but not the zero one. I am not even sure it would affect the temp2 reading...

Petteri P (petterip) wrote :

I think I solved my issue. The solution turned out to be the removal of the fglrx driver. After uninstalling the driver two days ago both temp1 and temp2 temperatures are nearly the same as before suspending and no more fans at full speed after resume. Silence... at last.

Tapio Valli (tapio-valli) wrote :

Confirming that #88 works on my HP ProBook 4510s, Ubuntu 12.04 64-bit.

Before the workaround, running "sensors" would give erratic readings after resume from suspend, one of the temp sensors went first to 90C, after plugging in AC for a second, it went step by step to 0C! But I do work in normal room temp :) After a while, a normal reading returned.

After the workaround, same behaviour as before with AC plug-on/off. Temp6 goes to 0C, fans normalize and after a while temp6 returns to comfortable 35C. It seems that, temp6 is switching between 0C and 35C, fan sound ok, on-off, as in normal state.

I have no fglrx installed, thus not removed.

Thomas Dahlmann (dahlmann) wrote :

On Ubuntu 12.04 with both stock kernel and 3.5 the problem is persitent (HP 5310m). I can fix it by unplugging/replugging the power cord or using this script (modified from above examples):

#!/bin/sh
#
# https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/77370
# file /etc/pm/sleep.d/99fancontrol.sh

case "$1" in
 hibernate|suspend)
  # Stopping is not required.
  ;;
 thaw|resume)
# In background.
  echo -n "1" > /sys/devices/virtual/thermal/cooling_device11/cur_state
  ;;
 *) exit $NA
  ;;
esac

This error has been around like in ages, why hasn't it bee fix by now?

I can confirm this on 12.10 with a HP Probook 4510s

> echo -n "1" > /sys/devices/virtual/thermal/cooling_device11/cur_state

This fixes it till the next time for me.

pd (petr-danecek) wrote :

I can also confirm that the above solves the problem. Apparently the kernel does not know what state are the fans in. This can be solved by turning them on and off for a brief period of time. Note that this does not turn the fans off permanently, the cooling is not affected and the fans continue to work normally. (Well, at least on my laptop.)

Here is the script above again made more general which scans all laptops:

touch /etc/pm/sleep.d/99fancontrol.sh
chmod +x /etc/pm/sleep.d/99fancontrol.sh

cat > /etc/pm/sleep.d/99fancontrol.sh
#!/bin/sh
#
# https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/77370
# file /etc/pm/sleep.d/99fancontrol.sh

case "$1" in
    hibernate|suspend)
    # Stopping is not required.
    ;;

    thaw|resume)
    # In background.
    ls /sys/devices/virtual/thermal/cooling_device*/cur_state | while read A; do echo 1 > $A; echo 0 > $A; done
    ;;

    *) exit $NA
    ;;
esac

Thomas Dahlmann (dahlmann) wrote :

I can confirm that the fix from "pd (petr-danecek)" works on my Probook 5310m. The fan comes out of "psychotic speed" mode and falls down to normal speed after resume.

Boy, have I been looking for this fix.

Can someone tell me why this hasn't been addressed yet, it is a very old bug?

Joel (ubu6tu) wrote :

Confirmed on HP ProBook 4510s.
On older versions of ubuntu this could be "solved" by plugging out the power coord and then plugging it back in some seconds later when the fan spinned down. After upgrading to 13.04, this metod no longer works.

sudo su
echo -n "1" > /sys/devices/virtual/thermal/cooling_device11/cur_state
^ That did nothing.

sudo su
ls /sys/devices/virtual/thermal/cooling_device*/cur_state | while read A; do echo 1 > $A; echo 0 > $A; done
^ That killed the fan. I mean killed, it totally stopped. So i changed it to only write a "1" (I got a bit nervous since "watch sensors" started to climb in temperature...), and then the fan was on at full speed again...

I also tried setting this in BIOS:
https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/322072/comments/2
from bug 322072 (kind of a duplicate I guess) - but it didn't work...

For me and others ( https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/322072/comments/3 ) the power coord method worked before, but not now after the 13.04. Maybe the answer to this can be found there, by what changed in the upgrade?

Joel (ubu6tu) wrote :

Uptade on this:
ls /sys/devices/virtual/thermal/cooling_device*/cur_state | while read A; do echo 1 > $A; echo 0 > $A; done
does kill the fan, but it starts again when the processor gets to 50*C.

Before it was more like it was on a little bit all the time and spun up when needed, now it is quiet for a while, spins up for a while, is quiet for a while etc. Not sure if that is better or just annoying, I think it is a bit annoying, but atleast it fixes the problem. It would be better if the fan didn't shut down completely but was held on a low level (like it behaves when started "normally") though. :)

Phillip Susi (psusi) wrote :

This report appears to have become an extended discussion of unresolved, unrelated problems over the years rather than describing a bug that can be worked on, so I am closing it. If you are still having an issue, please file your own bug report for your specific hardware, and include a tar of /sys/devices/virtual/thermal.

Changed in acpi (Ubuntu):
status: Confirmed → Invalid
Joel (ubu6tu) wrote :

That is a shame, when there is a working fix for atleast some (multiple) hardware. I think we (or I...) am just lacking competence of incorporating it into the codebase... Well, I could copy-paste the code mentioned above in a .diff/.patch - but that wouldn't be a nice integration, would it?

Dorin Scutarașu (dorins) wrote :

I've also run into this issue on my HP 6720s using Ubuntu 13.04 and linux 3.8.0-25.

I used the workaround posted by petr-daneck in comment #94, which worked nicely. Thanks Petr!

Steve Hughey (hugheyst) wrote :

Had this exact problem running Xubuntu 13.04 with kernel version 3.8.0-26 on an HP tc4400 laptop. petr-daneck's script fixed it for me. Thanks, Petr.

1 comments hidden view all 103 comments
Xiang (hsiang-liu) wrote :

1. before suspend, examine and remember all values of /sys/devices/virtual/thermal/cooling_device*/cur_state
2. after suspend, restore all values mentioned above.

OR, for simplicity, just set the values of /sys/devices/virtual/thermal/cooling_device*/cur_state periodically.

Displaying first 40 and last 40 comments. View all 103 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers