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

Pavel Machek
2006-05-22T09:56:30Z

Hi!

> > https://bugzilla.novell.com/show_bug.cgi?id=173420
>
> >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.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html