From patchwork Tue May 5 19:05:07 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Zajac X-Patchwork-Id: 21912 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n45J5EY1014958 for ; Tue, 5 May 2009 19:05:14 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752717AbZEETFM (ORCPT ); Tue, 5 May 2009 15:05:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753038AbZEETFL (ORCPT ); Tue, 5 May 2009 15:05:11 -0400 Received: from fg-out-1718.google.com ([72.14.220.155]:52978 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752717AbZEETFK (ORCPT ); Tue, 5 May 2009 15:05:10 -0400 Received: by fg-out-1718.google.com with SMTP id d23so881176fga.17 for ; Tue, 05 May 2009 12:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:date:user-agent :mime-version:content-disposition:subject:to:cc:content-type :content-transfer-encoding:message-id; bh=7E/q4eTfWBeQg+TygowaEDjJsANYT6N/fu09y8DwfFg=; b=wtQZTHVcV/gK7cFxzqyOp787xqWFfgUoGU2Ix4WlYvhNoal6PJJTu4Zx5Zygr+vCoL PpvJhQ+jf7I9M5tpFmwjJxzpDWjC+djLcL4m+adFD+AphvESMr9Fnvyr1H9DTKNR2vZH /MkA9EjrX1pPbQtYSpKKkBlzCziPGgga8L4yk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:user-agent:mime-version:content-disposition:subject:to:cc :content-type:content-transfer-encoding:message-id; b=D5hAFJDohA5r9EjRKKMANm7WdeXDeGzdZ5wDi6PWSl53XHjfTdGul1yCxpD4KbJfkY DyHiHoPTzYJO68Y81v4GOgPcjTDbMIBt12CKeB4XDkIPqtSpiiodc12WGmnuMohRkgfs 4sbEaCyn6FRBeeudBDeMoCl3HWt6HyrwQXhg0= Received: by 10.86.61.13 with SMTP id j13mr454161fga.68.1241550308219; Tue, 05 May 2009 12:05:08 -0700 (PDT) Received: from ?192.168.11.144? (host-77-247-224-23.isper.sk [77.247.224.23]) by mx.google.com with ESMTPS id 12sm13619704fgg.25.2009.05.05.12.05.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 12:05:07 -0700 (PDT) From: Vladimir Zajac Date: Tue, 5 May 2009 21:05:07 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Subject: PROBLEM: (regression) thermal zone - fan is turned on at higher temperature than it should To: rui.zhang@intel.com Cc: linux-acpi@vger.kernel.org, mjg59@srcf.ucam.org Message-Id: <200905052105.07316.eightgraph@gmail.com> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org [1.] One line summary of the problem: (regression) thermal zone - fan is turned on at higher temperature than it should [2.] Full description of the problem/report: After upgrade to 2.6.30-rc4 I noticed that my laptop's fan sometimes runs at lower speed than it used to. 2.6.29 does not have the bug. The laptop (HP Compaq 6710b) has 5 ACPI cooling devices which correspond to different fan speeds. They are not turned on when I expect them to be. Expected behavior: Each active cooling device should be turned on when current temperature is equal or higher than its trip point. (This is how it worked in 2.6.29 and earlier versions and also how it is defined by ACPI specification.) Actual behavior in 2.6.30-rc4: Each cooling device is turned on only when current temperature is strictly greater than the corresponding trip point but not when current temperature is equal to the trip point. It is caused by commit b1569e99c795bf83b4ddf41c4f1c42761ab7f75e: author Matthew Garrett Wed, 3 Dec 2008 17:55:32 +0000 (17:55 +0000) committer Len Brown Fri, 20 Feb 2009 23:41:56 +0000 (18:41 -0500) commit b1569e99c795bf83b4ddf41c4f1c42761ab7f75e ACPI: move thermal trip handling to generic thermal layer This commit (probably unintentionally) also changed how kernel determines if a cooling device has to be activated: before the commit: cooling device is activated if current temperature >= trip point temperature after the commit: cooling device is activated if current temperature > trip point temperature I tried to change the trip point test back to "temp >= trip_temp" in drivers/thermal/termal_sys.c (attached patch). It fixes the issue on my laptop. [3.] Keywords (i.e., modules, networking, kernel): acpi, thermal zone [4.] Kernel information [4.1.] Kernel version (from /proc/version): Linux version 2.6.30-rc4-64v01kms (root@V2G64) (gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5) ) #2 SMP PREEMPT Fri May 1 00:11:41 CEST 2009 [5.] Most recent kernel version which did not have the bug: 2.6.29 [X.] Other notes, patches, fixes, workarounds: patch which should fix the issue(for 2.6.30-rc4): Acked-by: Zhang Rui Acked-by: Matthew Garrett --- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- linux-2.6.30-rc4/drivers/thermal/thermal_sys.c 2009-04-30 23:52:59.000000000 +0200 +++ linux-2.6.30-rc4-p1/drivers/thermal/thermal_sys.c 2009-05-04 19:58:30.000000000 +0200 @@ -961,7 +961,7 @@ void thermal_zone_device_update(struct t switch (trip_type) { case THERMAL_TRIP_CRITICAL: - if (temp > trip_temp) { + if (temp >= trip_temp) { if (tz->ops->notify) ret = tz->ops->notify(tz, count, trip_type); @@ -974,7 +974,7 @@ void thermal_zone_device_update(struct t } break; case THERMAL_TRIP_HOT: - if (temp > trip_temp) + if (temp >= trip_temp) if (tz->ops->notify) tz->ops->notify(tz, count, trip_type); break; @@ -986,14 +986,14 @@ void thermal_zone_device_update(struct t cdev = instance->cdev; - if (temp > trip_temp) + if (temp >= trip_temp) cdev->ops->set_cur_state(cdev, 1); else cdev->ops->set_cur_state(cdev, 0); } break; case THERMAL_TRIP_PASSIVE: - if (temp > trip_temp || tz->passive) + if (temp >= trip_temp || tz->passive) thermal_zone_device_passive(tz, temp, trip_temp, count); break;