From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 24 01:44:55 2005
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
X-Original-To: freebsd-acpi@freebsd.org
Delivered-To: freebsd-acpi@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D998C16A41C
for <freebsd-acpi@freebsd.org>; Fri, 24 Jun 2005 01:44:55 +0000 (GMT)
(envelope-from nate@root.org)
Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22])
by mx1.FreeBSD.org (Postfix) with ESMTP id A6B5543D49
for <freebsd-acpi@freebsd.org>; Fri, 24 Jun 2005 01:44:55 +0000 (GMT)
(envelope-from nate@root.org)
Received: from [172.16.7.47] (pl114.nas941.n-yokohama.nttpc.ne.jp
[61.197.90.178])
by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j5O1iqqc008460
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Thu, 23 Jun 2005 18:44:53 -0700
Message-ID: <42BB645F.4010306@root.org>
Date: Thu, 23 Jun 2005 18:39:43 -0700
From: Nate Lawson <nate@root.org>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Alexandre \"Sunny\" Kovalenko" <Alex.Kovalenko@verizon.net>
References: <7cd06a2d05062205331d03372c@mail.gmail.com> <7cd06a2d050623073452e3c3f9@mail.gmail.com> <1130426516.777.7.camel@RabbitsDen>
<42BB28BD.5080202@root.org> <1130461569.1345.6.camel@RabbitsDen>
In-Reply-To: <1130461569.1345.6.camel@RabbitsDen>
Content-Type: text/plain; charset=ISO-8859-5; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-acpi@freebsd.org, Matthew Flanagan <flanagan.matt@gmail.com>
Subject: Re: Changing temperature threshold
X-BeenThere: freebsd-acpi@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ACPI and power management development <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2005 01:44:56 -0000
Alexandre "Sunny" Kovalenko wrote:
> On Thu, 2005-06-23 at 14:25 -0700, Nate Lawson wrote:
>
>>Alexandre "Sunny" Kovalenko wrote:
>>
>>>>When I try to raise hw.acpi.thermal.tz0._CRT to 85C (which is the
>>>>threshold in the BIOS setup) it doesn't work:
>>>>
>>>>bell# sysctl hw.acpi.thermal.tz0._CRT=3580 # 3580 tenths of Kelvin=85C
>>>>sysctl: oid 'hw.acpi.thermal.tz0._CRT' is read only
>>>>
>>>>Now, my question is: how do I change this value? I've read several
>>>>manpages (acpi(4), acpi_thermal(4), acpiconf(8), loader(8), and many
>>>>others) and checked the handbook, to no avail. Can anyone point me
>>>>to the right direction?
>>>
>>>One of the ways to deal with that would be to dump your ASL (see
>>>Handbook for guidance), find lines which look like:
>>> Method (_CRT, 0, NotSerialized)
>>> {
>>> Return (KELV (0x5d))
>>> }
>>>modify them to your liking, compile ASL and override it during boot
>>>(instructions on how to compile and override are in Handbook as well).
>>>Please, note that actual value returned is in the 1/10th of the degree
>>>of Kelvin. Function KELV above has following ASL code associated with
>>>it:
>>> Method (KELV, 1, NotSerialized)
>>> {
>>> Store (Arg0, Local1)
>>> Multiply (0x0A, Local1, Local1)
>>> Add (Local1, 0x0AAC, Local1)
>>> Return (Local1)
>>> }
>>>Thermal management chapter of the ACPI specification should provide you
>>>with ample explanation of what this is all about.
>>
>>This explanation is correct. The reason why the sysctl is read-only is
>>because the values are supplied by the BIOS and are what the OEM thinks
>>are critical temperatures. However, we need a way to allow override in
>>the case of obviously wrong values like this. I'll probably change it
>>to allow overriding from the loader but be read-only in sysctl to avoid
>>accidental changes from users experimenting.
>>
>
> Would you consider making ACx levels writeable while you are at that? It
> will make it much easier to implement thermal hysteresis from userland.
That's pretty scary too. While not as important as _CRT, if a user
changes a threshold to a high value, it's possible to damage the system.
I'll consider implementing that with some reasonable cap on values.
--
Nate