Fan remains off after resume (Hot Topic)

[David Becker]

After resuming from standby with an HP6715b, the fan remains off until I log out. Logging out causes the fan to resume.

libsensors provides 7 different temperature readings. Some of these exceed 115 C after resuming and if I don't manually intervene, the system doesn't automatically shut off. Maybe it'll eventually shut off, burn or melt, but I don't want to wait and see which outcome takes place.

What if I have this in the overhead compartment in a plane and the laptop for whatever reason resumes from standby? This is a serious hazard.

I never (recall) had (having) this problem when running Fedora 10, 11, 12 and 13.

David

[stoat]

I don't know one thing about fan control. Sorry. And this idea may not be something you're interested in. But if you discover a terminal command(s) that causes the fan to resume (e.g., unloading/reloading some module, restarting some service, etc.), then a possible thing to do is a pm-utils script in /etc/pm/sleep.d that can run commands upon entering and/or resuming from suspend or hibernation. People often do that to make wireless work after resuming. Just a thought. In case nothing better comes along.

[David Becker]

Originally Posted by stoat

I don't know one thing about fan control. Sorry. And this idea may not be something you're interested in. But if you discover a terminal command(s) that causes the fan to resume (e.g., unloading/reloading some module, restarting some service, etc.), then a possible thing to do is a pm-utils script in /etc/pm/sleep.d that can run commands upon entering and/or resuming from suspend or hibernation. People often do that to make wireless work after resuming. Just a thought. In case nothing better comes along.

Thanks for the tip. Your suggestion is actually what I'm trying to figure out. Since logging out causes the fan to spin, I'm trying to find out what I can do other than logging out in order to get the fan back on.

In previous Fedora releases, I was able to somewhat control the fan by cat'ing a value to /proc/acpi/fan/..., but this isn't working with any of the following:

# find /proc/acpi/fan/
/proc/acpi/fan/
/proc/acpi/fan/C39E
/proc/acpi/fan/C39E/state
/proc/acpi/fan/C39D
/proc/acpi/fan/C39D/state
/proc/acpi/fan/C39C
/proc/acpi/fan/C39C/state
/proc/acpi/fan/C39B
/proc/acpi/fan/C39B/state

Note that there's only one fan in this laptop. C39E/state is on while the rest are always off. After resuming, C39E/state remains off (until logging out).

David

[David Becker]

I think I've solved the problem by upgrading the BIOS from version F.0B to (the latest version) F.OE. Now the fan comes back when resuming and seems to function properly.

I can only infer that previous Fedora/Linux releases acommodated the older BIOS versions and that newer kernel releases don't match with the older BIOS(' ACPI tables).

Who knows, this may have also resolved the Broadcom disconnect issues I posted in a previous thread.

Thanks,

David

---------- Post added at 08:16 AM ---------- Previous post was at 07:12 AM ----------

It's still flakey. When going to standby again and resuming, the fan runs at the lowest speed and doesn't increase in speed with heavy processing. System continues to overheat, although somewhat less than when the fan wasn't running at all.

David

---------- Post added at 08:29 AM ---------- Previous post was at 08:16 AM ----------

And when I logout (of gnome), the fan behaviour is normal once again.