From owner-freebsd-acpi@FreeBSD.ORG Fri Mar 27 01:50:36 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 927B9106564A for ; Fri, 27 Mar 2009 01:50:36 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 41CB88FC0A for ; Fri, 27 Mar 2009 01:50:35 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so659303ywh.13 for ; Thu, 26 Mar 2009 18:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=7oICB1uBS1arzkv4IT2vwYivVCV1PaQFcl6MkUhnHts=; b=FbnDZbPQfkRLuuX//NZQYeF9EVaIvApzHmlaSgmLrOGmoKlWHvePmBlhA2g24e5SlF PsuS3BJt0rB3cNKeca1mTjnPuile1pOeEg5ghaBoY0fERxMOIz/tGqhtqCkYfx9sXtyT kQXc0snYACrnuNwjTqB/LYZcmAdgB4u4/xL+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=evTHEKzvHWrtzYIH+G1zTt8W4t6id9eHpPYMtIxVqyaycEt7m8tIcAMPeaFVUABOJc m954bZDDTA4HW9LWQm+qHigeW0zlUs1e+6RMK6/f8bMFxgYC2NhW/V9fggJX0oROpDRi LYI1D9AgKOO+/LxIVVtbTPtFlcw3UDbIrak+s= Received: by 10.90.66.10 with SMTP id o10mr901750aga.29.1238118635448; Thu, 26 Mar 2009 18:50:35 -0700 (PDT) Received: from ?10.0.3.231? (pool-71-250-44-232.nwrknj.east.verizon.net [71.250.44.232]) by mx.google.com with ESMTPS id 39sm1364398agd.43.2009.03.26.18.50.34 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Mar 2009 18:50:35 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Nate Lawson In-Reply-To: <49CC147A.3030805@root.org> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 26 Mar 2009 21:50:21 -0400 Message-Id: <1238118621.1365.35.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@FreeBSD.org, Ian Smith , Chris Whitehouse Subject: Re: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 01:50:37 -0000 On Thu, 2009-03-26 at 16:49 -0700, Nate Lawson wrote: > Chris Whitehouse wrote: > > Alexandre "Sunny" Kovalenko wrote: > >> To be fair, if all you want is to override _CRT, you should be able to > >> put something to the tune of > >> > >> hw.acpi.thermal.user_override=1 > >> hw.acpi.thermal.tz0._CRT=90C > >> > >> in your /etc/sysctl.conf and not deal with the ASL at all. > > > > I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until > > hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change > > values at which point hw.acpi.thermal.tz0._CRT reverts to -1. > > > > Thermal zones are re-evaluated when a Notify comes in that says to do > so. Perhaps if "user_override" is set to 1, we should not re-evaluate > them. However, perhaps that should only be done for values the user > actually overrode. ACPI 2.0 spec explicitly talks about updating of the _PSV and _ACx on Notify(..., 0x81). ACPI 3.0b is shade more vague, but still talking about "active and passive cooling temperature trip points". Maybe we should not reevaluate _HOT and _CRT at all? > > There has to be a different solution Windows used. Maybe they ignore _crt. Looking at ASL I can see five thermal zone objects defined and only one of them (TZ4) looking somewhat normal: _CRT is 110C and _TMP method goes to the trouble of making sane return value. Maybe Windows somehow knows which thermal zones to ignore? Given the snippet below this _was_ geared heavily towards Windows: If (\_OSI ("Windows 2001")) { Store (0x04, C014) } If (\_OSI ("Windows 2001 SP1")) { Store (0x04, C014) } If (\_OSI ("Windows 2001 SP2")) { Store (0x05, C014) } If (\_OSI ("Windows 2006")) { Store (0x06, C014) } Chris, you should be able to set hw.acpi.osname= in loader.conf and see if things improve somewhat. Note that "Windows 2001" and "Windows 2001 SP1" are identical. Could you also, please, post the full output of the sysctl hw.acpi.thermal -- Alexandre Kovalenko (Олександр Коваленко)