Skip site navigation (1)Skip section navigation (2) 
Date:      Wed, 3 May 2006 15:42:48 +0200
From:      Bruno Ducrot <ducrot@poupinou.org>
To:        Pav Lucistnik <pav@FreeBSD.org>
Cc:        freebsd-acpi@FreeBSD.org
Subject:   Re: acpi_thermal on nforce 4 board
Message-ID:  <20060503134248.GB31815@poupinou.org>
In-Reply-To: <1146585606.31507.38.camel@pav.hide.vol.cz>
References:  <1146231595.94164.25.camel@pav.hide.vol.cz> <20060502154819.GA16135@poupinou.org> <1146585606.31507.38.camel@pav.hide.vol.cz>
next in thread | previous in thread | raw e-mail | index | archive | help 
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.

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060503134248.GB31815>