Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 03 May 2006 15:57:12 +0200
From:      Pav Lucistnik <pav@FreeBSD.org>
To:        Bruno Ducrot <ducrot@poupinou.org>
Cc:        freebsd-acpi@FreeBSD.org
Subject:   Re: acpi_thermal on nforce 4 board
Message-ID:  <1146664632.38125.65.camel@pav.hide.vol.cz>
In-Reply-To: <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> <20060503134248.GB31815@poupinou.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--=-3CWEf9eCKa2eqpllfQxm
Content-Type: text/plain; charset=ISO8859-2
Content-Transfer-Encoding: quoted-printable

Bruno Ducrot p=ED=B9e v st 03. 05. 2006 v 15:42 +0200:
> On Tue, May 02, 2006 at 06:00:06PM +0200, Pav Lucistnik wrote:
> > Bruno Ducrot p=ED?e v =FAt 02. 05. 2006 v 17:48 +0200:
> > > Hi,
> > >=20
> > > On Fri, Apr 28, 2006 at 03:39:55PM +0200, Pav Lucistnik wrote:
> > > > Hi list!
> > > >=20
> > > > I recently got a new motherboard and CPU. I like to keep a tap on t=
he
> > > > CPU temperature. xmbmon utility no longer works on this hardware, s=
o I
> > > > turned to ACPI.
> > > >=20
> > > > Since I assembled the system on Monday, the temperature never chang=
ed:
> > > >=20
> > > > hw.acpi.thermal.tz0.temperature: 21.8C
> > > >=20
> > > > Is our acpi_thermal(4) supposed to work with nForce 4 chipsets?
> > >=20
> > > 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.
> > >=20
> > > > It's MSI Neo4-FI board, dmesg is at http://hood.oook.cz/techno/ I c=
an
> > > > get a verbose boot dmesg later, if needed. BIOS is latest (5.0).
> > >=20
> > > Could you please give a link to an acpidump output as well?
> >=20
> > http://raven.oook.cz/pav-nforce4.asl
> >=20
>=20
> Thanks.
>=20
> The problem is here:
>=20
>=20
>     Scope (\_TZ)
>     {
>         ...
>         ...
>=20
>         ThermalZone (THRM)
>         {
>             ...
>             ...
>             Method (_TMP, 0, NotSerialized)
>             {
>                 Return (0x0B86)
>             }
>             ...
> 	    ...
>=20
> Each time hw.acpi.thermal.tz0.temperature is readen, this
> AML method is called by our ACPI interpreter.
>=20
> As you can see, this method return the same value which
> correspond to 295 degree kelvin.
>=20
>=20
> Fortunately there are those methods:
>=20
>     OperationRegion (SEN1, SystemIO, 0x0295, 0x02)
>     ...
>     ...
>     Field (SEN1, ByteAcc, NoLock, Preserve)
>     {
>         SEI0,   8,=20
>         SED0,   8
>     }
>     ...
>     ...
>=20
>     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)
>         }
>=20
>         If (LEqual (SSHU, 0x01))
>         {
>             Return (0x0C3C)
>         }
>         Else
>         {
>             Return (Local0)
>         }
>     }
>=20
>     Method (WSEN, 2, NotSerialized)
>     {
>         Store (Arg0, SEI0)
>         Store (Arg1, SED0)
>     }
>=20
>     Method (RSEN, 1, NotSerialized)
>     {
>         Store (Arg0, SEI0)
>         Store (SED0, Local0)
>         Return (Local0)
>     }
>=20
>=20
> 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.
>=20
> 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.

Hmm, I'd rather not risk hanging of the system here.
I may play with this, thank you for the hints.

> BTW I don't see why mbmon failed.  Maybe you should
> try something like that:
>=20
> mbmon -P winbond

No, it just fails to work. And I just tried and it now fails to work on
boards where it used to work. Fishy...

# mbmon -D -p winbond
Probe Request: winbond
>>> Testing Reg's at ISA-IO <<<
[ISA Port IO-Base:0x290]
Probing Winbond/Asus/LM78/79 chip:
  CR40:0x01,  CR41:0x00,  CR42:0x10,  CR43:0xDE
  CR44:0xFF,  CR45:0xFF,  CR46:0x00,  CR47:0xD0
  CR48:0x2D,  CR49:0xFF,  CR4A:0x40,  CR4B:0x44
  CR4C:0x18,  CR4D:0x15,  CR4E:0x80,  CR4F:0x5C
  CR56:0x00,  CR58:0xA1,  CR59:0x70,  CR5D:0x01
  CR3E:0x83,  CR13:0x00,  CR17:0x3C,  CRA1:0xE9
  CR20:0xAB,  CR22:0xD4,  CR23:0xD4,  CR24:0xCB
  CR27:0x24,  CR29:0xFF,  CR2A:0x68,  CR2B:0xDA
No Hardware Monitor found!!
InitMBInfo: Unknown error: 0


--=20
Pav Lucistnik <pav@oook.cz>
              <pav@FreeBSD.org>

The number you dialed is imaginary.
Please turn your phone by 90 degrees and try again.

--=-3CWEf9eCKa2eqpllfQxm
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?=
	=?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?=
	=?ISO-8859-1?Q?_zpr=E1vy?=

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQBEWLa4ntdYP8FOsoIRAkttAJ91GrgndZVqTdkDAg2zhTvoMOOi8QCgojJD
Qn0WWuvNGenqrOLEY0uFfOg=
=iybZ
-----END PGP SIGNATURE-----

--=-3CWEf9eCKa2eqpllfQxm--



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