From owner-freebsd-acpi@FreeBSD.ORG  Wed May  3 13:42:51 2006
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 940F416A40A;
	Wed,  3 May 2006 13:42:51 +0000 (UTC)
	(envelope-from ducrot@poupinou.org)
Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 71B7D43D67;
	Wed,  3 May 2006 13:42:49 +0000 (GMT)
	(envelope-from ducrot@poupinou.org)
Received: from ducrot by poup.poupinou.org with local (Exim)
	id 1FbHcu-0008T1-00; Wed, 03 May 2006 15:42:48 +0200
Date: Wed, 3 May 2006 15:42:48 +0200
To: Pav Lucistnik <pav@FreeBSD.org>
Message-ID: <20060503134248.GB31815@poupinou.org>
References: <1146231595.94164.25.camel@pav.hide.vol.cz>
	<20060502154819.GA16135@poupinou.org>
	<1146585606.31507.38.camel@pav.hide.vol.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1146585606.31507.38.camel@pav.hide.vol.cz>
User-Agent: Mutt/1.5.9i
From: Bruno Ducrot <ducrot@poupinou.org>
Cc: freebsd-acpi@FreeBSD.org
Subject: Re: acpi_thermal on nforce 4 board
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: Wed, 03 May 2006 13:42:53 -0000

On Tue, May 02, 2006 at 06:00:06PM +0200, Pav Lucistnik wrote:
> Bruno Ducrot pí?e v út 02. 05. 2006 v 17:48 +0200:
> > Hi,
> > 
> > On Fri, Apr 28, 2006 at 03:39:55PM +0200, Pav Lucistnik wrote:
> > > Hi list!
> > > 
> > > I recently got a new motherboard and CPU. I like to keep a tap on the
> > > CPU temperature. xmbmon utility no longer works on this hardware, so I
> > > turned to ACPI.
> > > 
> > > Since I assembled the system on Monday, the temperature never changed:
> > > 
> > > hw.acpi.thermal.tz0.temperature: 21.8C
> > > 
> > > Is our acpi_thermal(4) supposed to work with nForce 4 chipsets?
> > 
> > acpi_thermal(4) is arch (in fact i386 ia64 and amd64) and chipset
> > independant.  It's therefore AML methods related to thermal zones
> > that's seems to be broken to my eyes.
> > 
> > > It's MSI Neo4-FI board, dmesg is at http://hood.oook.cz/techno/ I can
> > > get a verbose boot dmesg later, if needed. BIOS is latest (5.0).
> > 
> > Could you please give a link to an acpidump output as well?
> 
> http://raven.oook.cz/pav-nforce4.asl
> 

Thanks.

The problem is here:


    Scope (\_TZ)
    {
        ...
        ...

        ThermalZone (THRM)
        {
            ...
            ...
            Method (_TMP, 0, NotSerialized)
            {
                Return (0x0B86)
            }
            ...
	    ...

Each time hw.acpi.thermal.tz0.temperature is readen, this
AML method is called by our ACPI interpreter.

As you can see, this method return the same value which
correspond to 295 degree kelvin.


Fortunately there are those methods:

    OperationRegion (SEN1, SystemIO, 0x0295, 0x02)
    ...
    ...
    Field (SEN1, ByteAcc, NoLock, Preserve)
    {
        SEI0,   8, 
        SED0,   8
    }
    ...
    ...

    Method (RTMP, 0, NotSerialized)
    {
        WSEN (0x4E, 0x01)
        Store (RSEN (0x50), Local0)
        If (LLess (Local0, 0x80))
        {
            Multiply (Local0, 0x0A, Local0)
            Add (Local0, 0x0AAC, Local0)
        }
        Else
        {
            Subtract (Local0, 0x80, Local0)
            Multiply (Local0, 0x0A, Local0)
            Subtract (0x0AAC, Local0, Local0)
        }

        If (LEqual (SSHU, 0x01))
        {
            Return (0x0C3C)
        }
        Else
        {
            Return (Local0)
        }
    }

    Method (WSEN, 2, NotSerialized)
    {
        Store (Arg0, SEI0)
        Store (Arg1, SED0)
    }

    Method (RSEN, 1, NotSerialized)
    {
        Store (Arg0, SEI0)
        Store (SED0, Local0)
        Return (Local0)
    }


which apparently correspond to a winbond chip.  I
guess the intend of the bios writer was to call RTMP()
under _TMP() but QA failed to validate this since it is
expected methods are thread safe, and those methods
are not thread safe for sure.

It maybe possible if we do something like that:
            Method (_TMP, 0, NotSerialized)
            {
                Return (RTMP())
            }
then we should be able to get correct values, but the
chip could hang in the long run.


BTW I don't see why mbmon failed.  Maybe you should
try something like that:

mbmon -P winbond

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.