Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

From: Pavel Machek
Date: Mon May 22 2006 - 05:56:29 EST


> >
> >From Comment #30 at the above url: "The Linux ACPI code seems to
> actively prevent the fan from running and that worries me."
> I saw that as well, and found the following recipe would work around
> the problem:
> 1. Set the trip point to, say, 70 C -- well above the actual
> temperature.
> 2. Then set the trip to anything reasonable that's under the current
> temperature (27 C always works). Now the fan turns on, and behaves
> fine from then.
> My explanation is that, before step 1, the fan is off but the OS
> thinks it's on. So the dialogue goes something like:
> Hardware (from EC or BIOS?): Ack, I'm overheating, turn on the fan now!
> OS: There, there, take it easy. I've checked bit fields in my
> memory, and the fan is on. So I don't have to do anything.
> Hardware: Ack, ...
> OS: There, there, ...
> [Hence the 100% kacpid CPU usage]
> Based on this explanation, I added a resume method to the fan driver.
> It would turn on the fan and mark it as on. So then the internal OS
> state matched the actual state. The fix didn't work for at least one
> reason: ACPI drivers didn't have suspend/resume methods (though now
> there are test patches to add those methods).

Can you redo your patches with those methods?

> Another fix, probably worth doing anyway, is to turn on the fan if the
> BIOS asks for it, whether or not the OS thinks it's on. The chance of
> the two pieces of information getting out of synch, and the hardware
> damage it can cause, is enough to make it worthwhile. The reverse

There should be 0% hardware damage chance. Fan failure means overheats
mean emergency power cutoff. I even tested it with paper into fan
blades several times. It mostly works.
(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at