[Hewlett-Packard HP Compaq 6735s and 6710b] noisy fan after resume on HP (reproducibility about 20%)

[Donatello Bussacchini]

Sometimes, after a resume, the fan runs at full speed until the system is completely shutdown. Another suspend/resume won't resolve this issue.

Analysis
/proc/acpi/fan/FAN(0|1|2|3)/state give the state of the fan. After a resume, the bios activates the fan at full speed. And these variables should be updated.
Most of the time, at least, one of these variables is set to "on" and Linux lower the fan speed after the resume.
However sometimes all these variables are set to off (whereas the fan is running at full speed). In this case, the fan will remain at full speed.

Workaround
The workaround is to launch a program consuming a lot of CPU power, like burnK7. When the temperature reaches the first trip point (/proc/acpi/thermal_zone/CPUZ/trip_points), Linux activates the fan, and the fan speed is then reduced.

uname-a
Linux non-carus 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
NonfreeKernelModules: fglrx
Package: linux-image-2.6.27-11-generic 2.6.27-11.27
ProcCmdLine: User Name=UUID=d0140d59-c4e4-46fa-82d9-078ce590db6e ro quiet splash
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.27-11.27-generic
SourcePackage: linux

[Icek (petr-mahdalicek)]

I have the same notebook and the same problem. I don't thing it has anything to do with linux, look here http://forums11.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1298279 , it looks like bios bug to me.

[voneiden (snaipperi)]

Suspend works just fine with Windows XP/Vista. I've been trying around with Intrepid (Ubuntu/Kubuntu) and Ubuntu Hardy and all of these experience the problem. Currently,

$ uname -r
2.6.24-23-generic

For me, this workaround has not worked. After suspend resume the fan states are set to 3. My only workaround for this has been to echo 0 to the fan states, and then echo them back to state 3 and make sure that polling is turned on.

After suspend resume acpi_listen does not show any events, even when trip points are reached, thus without polling enabled the fans will be spinning on whatever speed the bios sets them on suspend resume.

This however is a no-good solution, as even with polling, ACPI doesn't update the trip points when a fan is turned on/off, which basically results in the temperature bouncing +-2C around the active[2] trip point, fans constantly turning on and off.

[polluz (francesco-pollamattiot)]

Same laptop and i confirm the same problem.

Bye!

[Ingo Karkat (inkarkat)]

The problem persists with Ubuntu 9.04 Jaunty Jackalope; I have the same HP 6735s (default install, but running the proprietary ATI fglrx driver). Found no working workaround except reboot yet; heated the notebook to 71*C, but fan kept spinning fast.

[Donatello Bussacchini (dbussacchini)]

You must set the polling frequency at startup. I forgotten that.
echo -n 5 > /proc/acpi/thermal_zone/CPUZ/polling_frequency

So how the workaround works.

The PC resumes with fan at full speed but /proc/acpi/fan/FAN? are set to off. It is impossible to stop the fan because Linux thinks the fan is already off. It is impossible to start the fan because the temperature is too low

Workaround:
- raise the CPU's temperature with cpu burn
- when the first trip point is reached, Linux turns on the fan. If polling_frequency has been configured
- stop cpu burn
- Linux turns off the fan

Another workaround, and simpler one, is to hibernate.

[voneiden (snaipperi)]

Donatello, your method is flawed, as the trip_points don't get updated anymore on trip events even if temperature polling is set on. This results in the temperature bouncing around a static trip point causing the fans to turn on and off way too often.

[Ingo Karkat (inkarkat)]

FYI: The script 99funguj in Ubuntu bug #77370 implements a simpler (and quicker) workaround that doesn't require heating the CPU until a trip point is reached.
However, one still needs to enable polling so that the fan keeps reacting to changes in CPU temperature after resuming from standby, even though this has the negative side effects mentioned by voneiden.

It seems to me that the root cause of the problem is that no ACPI events are received any more after resuming from standby, and that the noisy fan is just the easily observable manifestation. I'll gladly provide additional debugging information from my notebook if someone needs that to look into the problem.

[larppaxyz (larppaxyz-gmail)]

I noticed that reloading module named 'thermal' usually helps. I even made cron entry that does rmmod thermal; modprobe thermal every five minutes or so.

Now that i have stock 9.04 kernel, thermal is not compiled as module and i came to look for solution.

[Tomas Pospisek (tpo-deb)]

HP Compaq 6710b here. Fan allways worked well... until I upgraded to Karmic. Now, if I resume from suspen, the fan goes to chainsaw fullspeed mode.

The workaround above - heating both cpus, in my case I start this script here twice (for each core):

  #!/bin/sh
  while true; do i=$(( i + 1 ); done

and stop it after a few seconds. Then the system will cool down and the fans will spin down. I have yet to try the script from bug #77370.

It's a regression for me, because fan's were behaving well since Hardy.

[u2ix (u2ix)]

same here, ubuntu 9.10 amd64 on a hp compaq 6735b

[It's Easy (itiseasy-org)]

In mine HP Compaq 6735s is the same problem.This problem is only in Ubuntu Karmic.
How to fix this?

[u2ix (u2ix)]

Ingo Karkat posted a link to bug bug #77370 where a vasek125 posted a script which resolve the problem.

[Ivan Gualandri (ivang)]

I have the same problem on my hp 6735s,
But not only after resume, but after about 30-40 mins of execution.

[Jeremy Foshee (jeremyfoshee)]

Hi Donatello,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Donatello Bussacchini (dbussacchini)]

Problem also reproduced with:
Linux non-carus 2.6.31-02063112-generic #02063112 SMP Tue Jan 19 12:41:11 UTC 2010 i686 GNU/Linux
Since Ubuntu 9.10 the problem is apparently systematic.

[Jeremy Foshee (jeremyfoshee)]

Declining the Maverick specific nomination for now and leaving this open against the actively developed Ubuntu kernel (which happens to be Maverick at this time). Will re-open the nomination should a fix be narrowed down which we can confirm specifically resolves this issue in Maverick.

~JFo

[LostinSpacetime (lostinspacetime)]

I'm having the same issue with 6735b laptop. Using updated Maverick.

[Brad Figg (brad-figg)]

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.