acpi_thermal on nforce 4 board

[Pav Lucistnik]

Bruno Ducrot píše 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í?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.

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:
> 
> 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


-- 
Pav Lucistnik <pav at oook.cz>
              <pav at FreeBSD.org>

The number you dialed is imaginary.
Please turn your phone by 90 degrees and try again.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: 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?=
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20060503/94e5394e/attachment.pgp