Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751027AbWEVJ4b (ORCPT ); Mon, 22 May 2006 05:56:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751022AbWEVJ4b (ORCPT ); Mon, 22 May 2006 05:56:31 -0400 Received: from gprs189-60.eurotel.cz ([160.218.189.60]:37344 "EHLO amd.ucw.cz") by vger.kernel.org with ESMTP id S1751018AbWEVJ4a (ORCPT ); Mon, 22 May 2006 05:56:30 -0400 Date: Mon, 22 May 2006 11:55:31 +0200 From: Pavel Machek To: Sanjoy Mahajan Cc: trenn@suse.de, "Yu, Luming" , linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton , Tom Seeley , Dave Jones , Jiri Slaby , michael@mihu.de, mchehab@infradead.org, v4l-dvb-maintainer@linuxtv.org, video4linux-list@redhat.com, Brian Marete , Ryan Phillips , gregkh@suse.de, linux-usb-devel@lists.sourceforge.net, "Brown, Len" , linux-acpi@vger.kernel.org, Mark Lord , Randy Dunlap , jgarzik@pobox.com, linux-ide@vger.kernel.org, Duncan <1i5t5.duncan@cox.net>, Pavlik Vojtech , linux-input@atrey.karlin.mff.cuni.cz, Meelis Roos , Carl-Daniel Hailfinger Subject: Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT] Message-ID: <20060522095531.GC25624@elf.ucw.cz> References: <1148046258.9319.441.camel@queen.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.11+cvs20060126 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2191 Lines: 52 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/