Overheating Laptop

[Derek Broughton]

Pastor JW wrote:

> On Monday 16 June 2008 08:23:29 am Derek Broughton wrote:
>>
>> Er, yes :-)  But the fact is that ACPI implementations are often buggy,
>> and tested only on Windows, so things like fan controls fairly frequently
>> work better in Windows than Linux.
> 
> You know, I think our OS developers really ought to spend a little more
> time to address this and fix the install process.

Our developers have spent a _lot_ of time on this - I know because I hung
out on the acpi-devel list for a couple of years.  The problem is that it's
part of the BIOS.  If your system is really broken, you can force load a
new DSDT (don't ask what that stands for) but it's a pain.  When I was
hanging out on the developer's list, that was pretty much your only
recourse.  These days, it's almost never necessary, because our kernel
developers have done a really good job of working around most of the bugs,
but there's only so much you can do when the underlying firmware is flawed.

>> The sensors command was telling me my laptop was at 71C:
>> $ sensors
>> coretemp-isa-0000
>> Adapter: ISA adapter
>> Core 0:      +71.0°C  (crit = +100.0°C)
> 
> My machine doesn't even have this command! It gives:
> 
> $ sensors
> No sensors found!
> Make sure you loaded all the kernel drivers you need.
> Try sensors-detect to find out which these are.
> 
> Now how would an average user know which modules to work with? 

If acpi is working, you shouldn't need to know :-)  sensors isn't installed
by default, partly because it won't necessarily tell you anything useful,
anyway.

>> yet:
>> $  cat /proc/acpi/thermal_zone/*/temperature
>> temperature:             0 C
> 
> yet this  command gives:
> $  cat /proc/acpi/thermal_zone/*/temperature
> temperature:             42 C

Because yours is working...
> 
>> Now, I knew I'd seen a value there before, so figured that the "thermal"
>> module was broken somehow (note, I used the * in that path because there
>> is no way to say exactly what the ACPI controls are named on any
>> particular system - this seems to be at the root of some later statements
>> about files
>> being "missing" - not all systems have the same files).  So I did:
>> $ sudo modprobe thermal -r
>> $ sudo modprobe thermal
> 
> A "remove and replace"?  ...but if the module is bad in the first place,
> wouldn't it just continue to be bad? Or did I miss something?

I am guessing (but it's just a guess) that hibernate basically broke that
particular running program.  

>> And, voila, the fan promptly started up at low speed and brought the
>> temperature fairly quickly down to 50C (now visible in /proc/acpi/...)
>> before turning off.  I suspect it's not resuming properly after
>> hibernate, so if I ever find out (again) where to set that for pm, I'll
>> have it remove "thermal" before hibernating, then insert it on resume.
> 
> Or are you saying hibernate corrupts the module?  or does something
> permanently turn off the sensor so the module gets no input.

Could be either one.  Hibernate has been known to do that sort of thing -
it's part of the standard process, for instance, to "ifdown" all the
network interfaces and then remove the kernel modules, then restore them
after resume.  This works so well, that when my power goes out, and for
some reason my NIC won't communicate with the wireless router after the
power is back, I just hibernate/resume and the network is flawless. 
acpi-support provides a config option to do the same with any
user-specified module, but now I'm using pm-utils and I can't figure out
where to do the same thing.
-- 
derek