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

[Pavel Machek <pavel@suse.cz>]

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