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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html