Sensors on Asus P2B-F?

[Hauke Fath-2]

Hi,

after setting up net/mrtg on an oldish PIII@Asus P2B-F, I cannot get
any sensor data from the board:

# envstat
envstat: no drivers registered

# uname -a
NetBSD Riffel 5.0_STABLE NetBSD 5.0_STABLE (GENERIC) #0: Mon Sep 21
19:58:28 CEST 2009
hf@Hochstuhl:/var/obj/netbsd-builds/5/i386/sys/arch/i386/compile/GENERIC
i386


On the other hand...

# mbmon -d -A
Summary of Detection:
  * SMB monitor(s)[IntelPIIX4(440BX/MX)]:
   ** Asus Chip AS99127F found at slave address: 0x5A.


Since this is a GENERIC kernel, I'd have expected things to just
work. What am I missing, and/or which switch do I need to flick to
read sensor data from the board?

        hauke

--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Hauke Fath-2]

At 10:35 Uhr -0700 30.10.2009, Paul Goyette wrote:
>Once you've identified the sensors on your machine, you need to
>build custom kernel to include them.  In your case, this would be an
>lm(4) device.  You need to convert the i2c address to be
>"right-justified", so you'll need
>
> lm0 at iic? addr 0x2d

Thanks, Paul. Is there any obvious documentation that I overlooked,
or do you just have to know?

I built a kernel from home, and booted it blindly, and the machine
didn't come back. So that'll have to wait till Monday...

        hauke

--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Paul Goyette]

Mostly, you just have to know.

The iic manpage documents the I2C_SCAN option and tells you why we don't
autoscan the i2c bus.  Even scanning the bus simply tells you which
addresses respond;  there is in general no way to know for sure what is
at each address.  Not like PCI bus where there is a standardized Vendor
and Product code.

Some addresses are 'reserved', such as 0x50 thru 0x57 for spdmem(4).
But mostly you just have to know what device is where.



On Fri, 30 Oct 2009, Hauke Fath wrote:

> At 10:35 Uhr -0700 30.10.2009, Paul Goyette wrote:
>> Once you've identified the sensors on your machine, you need to build
>> custom kernel to include them.  In your case, this would be an lm(4)
>> device.  You need to convert the i2c address to be "right-justified", so
>> you'll need
>>
>> lm0 at iic? addr 0x2d
>
> Thanks, Paul. Is there any obvious documentation that I overlooked, or do you
> just have to know?
>
> I built a kernel from home, and booted it blindly, and the machine didn't
> come back. So that'll have to wait till Monday...
>
> hauke
>
> --
>     The ASCII Ribbon Campaign                    Hauke Fath
> ()     No HTML/RTF in email            Institut für Nachrichtentechnik
> /\     No Word docs in email                     TU Darmstadt
>     Respect for open standards              Ruf [phone]
>

-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------

[David Young]

On Fri, Oct 30, 2009 at 02:35:02PM -0700, Paul Goyette wrote:
> But mostly you just have to know what device is where.

Can reliable information be found in an ACPI table?

Dave

--
David Young             OJC Technologies
dyoung@...      Urbana, IL * [phone]

[Paul Goyette]

It's possible.  But I haven't found any documentation on how to actually
identify what is where.  Heck, most of the time the I2C/SMBus isn't even
identified in the DSDT.

Most of my machines (3 out of 5) are running ASUS MoBo's and although
every machine has one or more I2C busses, none of them are listed in the
ACPI tables.

If someone knows of any standards in this area, I'll be happy to dive
deeper.


On Fri, 30 Oct 2009, David Young wrote:

> On Fri, Oct 30, 2009 at 02:35:02PM -0700, Paul Goyette wrote:
>> But mostly you just have to know what device is where.
>
> Can reliable information be found in an ACPI table?
>
> Dave
>
> --
> David Young             OJC Technologies
> dyoung@...      Urbana, IL * [phone]
>

-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------

[Jukka Ruohonen-3]

On Fri, Oct 30, 2009 at 03:06:32PM -0700, Paul Goyette wrote:
> It's possible.  But I haven't found any documentation on how to actually
> identify what is where.  Heck, most of the time the I2C/SMBus isn't even
> identified in the DSDT.

This is my impression too.

In laptops, for instance, the I2C/SMBus is typically deliberately hidden.
But if something is connected, it is likely exposed only via ACPI. As an
example, some recent Asus boards contain a specific ACPI interface (HID
"ATK0110") for the sensors. Moreover, because the wiring of the sensors may
be unclear, or because ACPI may claim the related resources, it may be
dangerous to scan the I2C bus on such machines.

> If someone knows of any standards in this area, I'll be happy to dive
> deeper.

The new ACPI 4.0 specification has something to offer here in terms of
"power meters".

- Jukka.

[Hauke Fath-2]

At 22:15 Uhr +0100 30.10.2009, Hauke Fath wrote:
>I built a kernel from home, and booted it blindly, and the machine
>didn't come back. So that'll have to wait till Monday...

The kernel got stuck because of missing raidframe support, no big
deal. Beyond that, things are getting interesting...

So, the kernel config file (trying to catch every possible occurence
of lm(4)) has


# LM7[89] and compatible hardware monitors
lm0     at isa? port 0x290              # other common: 0x280, 0x310
lm1     at isa? port 0x280
lm2     at isa? port 0x310

# P2B has an Asus Chip AS99127F
#
# > # mbmon -d -A
# Summary of Detection:
# * SMB monitor(s)[IntelPIIX4(440BX/MX)]:
#  ** Asus Chip AS99127F found at slave address: 0x5A.
#
# <Paul Goyette> In your case, this would be an lm(4) device.  You
# need to convert the i2c address to be "right-justified", so you'll
# need </Paul Goyette>
#
lm*     at iic? addr 0x2d # Paul
lm*     at iic? addr 0x2e # lm(4)
lm*     at iic? addr 0x5a # Just in case
lm*     at iic? # openbsd does that


But all I get from the resulting kernel is


# envstat
envstat: no drivers registered
# dmesg | grep lm
#


-- same for a 5_99_21 current kernel. Again, mbmon happily reports


# mbmon -d -A
Summary of Detection:
  * SMB monitor(s)[IntelPIIX4(440BX/MX)]:
   ** Asus Chip AS99127F found at slave address: 0x5A.
# mbmon

Temp.= 32.0, 30.0,  0.0; Rot.= 3409,    0,    0
Vcore = 2.06, 2.51; Volt. = 3.65, 5.05, 11.86, -12.70, -5.14
^C
#


Any ideas?

        hauke






--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Martin Husemann]

On Mon, Nov 02, 2009 at 02:52:56PM +0100, Hauke Fath wrote:
> # dmesg | grep lm
> #

what about iic?

I would expect something like:

piixpm0: vendor 0x1166 product 0x0200 (rev. 0x50)
piixpm0: polling
iic0 at piixpm0: I2C bus
lm0 at iic0 addr 0x2d


Martin

[Hauke Fath-2]

At 15:13 Uhr +0100 02.11.2009, Martin Husemann wrote:

>On Mon, Nov 02, 2009 at 02:52:56PM +0100, Hauke Fath wrote:
>>  # dmesg | grep lm
>>  #
>
>what about iic?
>
>I would expect something like:
>
>piixpm0: vendor 0x1166 product 0x0200 (rev. 0x50)
>piixpm0: polling
>iic0 at piixpm0: I2C bus
>lm0 at iic0 addr 0x2d

So did I; but all I get is

[...]
piixpm0 at pci0 dev 4 function 3
piixpm0: vendor 0x8086 product 0x7113 (rev. 0x02)
timecounter: Timecounter "piixpm0" frequency 3579545 Hz quality 900
piixpm0: 24-bit timer
piixpm0: interrupting at SMI, polling
iic0 at piixpm0: I2C bus
wm0 at pci0 dev 9 function 0: Intel i82541PI 1000BASE-T Ethernet, rev. 5
wm0: interrupting at irq 5
wm0: 32-bit 33MHz PCI bus
[...]

- no lm*, ever.

        hauke

--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Martin Husemann]

On Mon, Nov 02, 2009 at 04:02:17PM +0100, Hauke Fath wrote:
> iic0 at piixpm0: I2C bus

Ok - just checking that you get the iic at all (if not, that would have
explained the missing lm too).

Martin

[Paul Goyette]

On Mon, 2 Nov 2009, Hauke Fath wrote:

> So did I; but all I get is
>
> [...]
> piixpm0 at pci0 dev 4 function 3
> piixpm0: vendor 0x8086 product 0x7113 (rev. 0x02)
> timecounter: Timecounter "piixpm0" frequency 3579545 Hz quality 900
> piixpm0: 24-bit timer
> piixpm0: interrupting at SMI, polling
> iic0 at piixpm0: I2C bus
> wm0 at pci0 dev 9 function 0: Intel i82541PI 1000BASE-T Ethernet, rev. 5
> wm0: interrupting at irq 5
> wm0: 32-bit 33MHz PCI bus
> [...]
>
> - no lm*, ever.

OK, your i2c bus is defined.

1. There's a LMDEBUG option which can be used to enable a debug printf()
    in the bus-independant probe routine.

2. Please also enable I2C_SCAN option (read the warning in options(4)
    man page!)

3. Make sure your kernel build includes the file sys/dev/ic/nslm7x.c


-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------

[Hauke Fath-2]

At 8:38 Uhr -0800 02.11.2009, Paul Goyette wrote:
>OK, your i2c bus is defined.
>
>1. There's a LMDEBUG option which can be used to enable a debug printf()
>    in the bus-independant probe routine.

Applied.

>2. Please also enable I2C_SCAN option (read the warning in options(4)
>    man page!)

Read and applied.

>3. Make sure your kernel build includes the file sys/dev/ic/nslm7x.c

Check.

The resulting kernel is very chatty, but has

Nov  2 18:54:42 Riffel /netbsd: iic0 at piixpm0: I2C bus
Nov  2 18:54:42 Riffel /netbsd: lm_probe: rv = 0, cr = 69
Nov  2 18:54:42 Riffel /netbsd: lm_probe: rv = 1, cr = 1
Nov  2 18:54:42 Riffel /netbsd: lm3 at iic0 addr 0x2e
Nov  2 18:54:42 Riffel /netbsd: wb_match: winbond vend id 0x6f6f
Nov  2 18:54:42 Riffel /netbsd:
Nov  2 18:54:42 Riffel /netbsd: lm3: Unknown chip (ID 88)
Nov  2 18:54:42 Riffel /netbsd: lm_probe: rv = 1, cr = 1
Nov  2 18:54:42 Riffel /netbsd: lm4 at iic0
Nov  2 18:54:42 Riffel /netbsd: wb_match: winbond vend id 0x0
Nov  2 18:54:42 Riffel /netbsd:
Nov  2 18:54:42 Riffel /netbsd: lm4: Unknown chip (ID 88)

and says

[hf@Riffel] /var/log # envstat
               Current  CritMax  CritMin  CritCap     Unit
[lm3]
   VCore A:      0.272                                   V
   VCore B:      1.408                                   V
     +3.3V:      1.408                                   V
       +5V:      2.365                                   V
      +12V:      5.632                                   V
      -12V:     -5.632                                   V
       -5V:     -2.347                                   V
     Temp0:    -36.000                                degC
      Fan0:       7670                                 RPM
      Fan1:       7670                                 RPM
      Fan2:       7670                                 RPM
[lm4]
   VCore A:      1.408                                   V
   VCore B:      1.408                                   V
     +3.3V:      1.408                                   V
       +5V:      2.365                                   V
      +12V:      5.632                                   V
      -12V:     -5.632                                   V
       -5V:     -2.347                                   V
     Temp0:    -36.000                                degC
      Fan0:       7670                                 RPM
      Fan1:       7670                                 RPM
      Fan2:       7670                                 RPM
[hf@Riffel] /var/log #

The values are a bit off, though... I guess the "Unknown chip id"
needs to be registered somewhere?

        hauke

--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Paul Goyette]

On Mon, 2 Nov 2009, Hauke Fath wrote:

> At 8:38 Uhr -0800 02.11.2009, Paul Goyette wrote:
>> OK, your i2c bus is defined.
>>
>> 1. There's a LMDEBUG option which can be used to enable a debug printf()
>>    in the bus-independant probe routine.
>
> Applied.
>
>> 2. Please also enable I2C_SCAN option (read the warning in options(4)
>>    man page!)
>
> Read and applied.
>
>> 3. Make sure your kernel build includes the file sys/dev/ic/nslm7x.c
>
> Check.
>
> The resulting kernel is very chatty, but has
>
> Nov  2 18:54:42 Riffel /netbsd: iic0 at piixpm0: I2C bus

Hmmm.  If you applied I2C_SCAN, I would have expected to see another
line similar to

iic0: devices at 0x2e 0x50 0x51

> Nov  2 18:54:42 Riffel /netbsd: lm_probe: rv = 0, cr = 69
> Nov  2 18:54:42 Riffel /netbsd: lm_probe: rv = 1, cr = 1
> Nov  2 18:54:42 Riffel /netbsd: lm3 at iic0 addr 0x2e
> Nov  2 18:54:42 Riffel /netbsd: wb_match: winbond vend id 0x6f6f
> Nov  2 18:54:42 Riffel /netbsd:
> Nov  2 18:54:42 Riffel /netbsd: lm3: Unknown chip (ID 88)
> Nov  2 18:54:42 Riffel /netbsd: lm_probe: rv = 1, cr = 1
> Nov  2 18:54:42 Riffel /netbsd: lm4 at iic0
> Nov  2 18:54:42 Riffel /netbsd: wb_match: winbond vend id 0x0
> Nov  2 18:54:42 Riffel /netbsd:
> Nov  2 18:54:42 Riffel /netbsd: lm4: Unknown chip (ID 88)

Hmmm.  That's an unknown vendor ID as well as an unknown chip.

>
> and says

Looks like the debug printf() has prevented the match routine from
returning a failure indication!  With the unknown vendor/chip id's, we
should never have matched or attached, and none of the following should
have been possible.  :)  I'll have a look at fixing that soon.

>
> [hf@Riffel] /var/log # envstat
>              Current  CritMax  CritMin  CritCap     Unit
> [lm3]
>  VCore A:      0.272                                   V
>  VCore B:      1.408                                   V
>    +3.3V:      1.408                                   V
>      +5V:      2.365                                   V
>     +12V:      5.632                                   V
>     -12V:     -5.632                                   V
>      -5V:     -2.347                                   V
>    Temp0:    -36.000                                degC
>     Fan0:       7670                                 RPM
>     Fan1:       7670                                 RPM
>     Fan2:       7670                                 RPM
> [lm4]
>  VCore A:      1.408                                   V
>  VCore B:      1.408                                   V
>    +3.3V:      1.408                                   V
>      +5V:      2.365                                   V
>     +12V:      5.632                                   V
>     -12V:     -5.632                                   V
>      -5V:     -2.347                                   V
>    Temp0:    -36.000                                degC
>     Fan0:       7670                                 RPM
>     Fan1:       7670                                 RPM
>     Fan2:       7670                                 RPM
> [hf@Riffel] /var/log #
>
> The values are a bit off, though... I guess the "Unknown chip id" needs to be
> registered somewhere?

Pretty much, we're reading nonsense.  This is to be expected if there is
either no device there, or if the device there doesn't behave as
expected (ie, doesn't respond to specific "commands").


-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------

[Hauke Fath-2]

At 10:39 Uhr -0800 02.11.2009, Paul Goyette wrote:
>>  The resulting kernel is very chatty, but has
>>
>>  Nov  2 18:54:42 Riffel /netbsd: iic0 at piixpm0: I2C bus
>
>Hmmm.  If you applied I2C_SCAN, I would have expected to see another
>line similar to
>
>iic0: devices at 0x2e 0x50 0x51

That kernel was built with options {LMDEBUG,I2C_SCAN}, but without DEBUG.

Adding DEBUG to the config indeed results in

[...]
piixpm0: 24-bit timer
piixpm0: interrupting at SMI, polling
iic0 at piixpm0: I2C bus
lm_probe: rv = 0, cr = 69
[...]

        hauke

--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Hauke Fath-2]

At 4:54 Uhr -0800 03.11.2009, Paul Goyette wrote:
>I have just fixed the piixpm code to set the bus type field.  This
>will enable the I2C_SCAN code to actually work.  Can you grab rev
>1.30 of src/sys/dev/pci/piixpm.c and rebuild and try again?
>
>I really doubt that what you have on this motherboard is a real lm
>chip, based on its strange behavior.

...better. A lot better.

# mbmon -d -A
Summary of Detection:
  * SMB monitor(s)[IntelPIIX4(440BX/MX)]:
   ** Asus Chip AS99127F found at slave address: 0x5A.
# mbmon

Temp.= 32.0, 28.0,  0.0; Rot.= 3341,    0,    0
Vcore = 2.06, 2.51; Volt. = 3.65, 5.05, 11.86, -12.82, -5.14
^C
# envstat
               Current  CritMax  CritMin  CritCap     Unit
[lm0]
   VCore A:      2.064                                   V
   VCore B:      2.512                                   V
     +3.3V:      3.648                                   V
       +5V:      5.053                                   V
      +12V:     11.856                                   V
      -12V:    -11.237                                   V
       -5V:     -5.153                                   V
     Temp0:     32.000                                degC
     Temp1:      0.000                                degC
     Temp2:      0.000                                degC
      Fan0:       3341                                 RPM
      Fan1:        N/A
      Fan2:        N/A
#

-- Note that Temp1 is missing, but the rest of the values match the
mbmon output.

dmesg has

Nov  3 15:37:33 Riffel /netbsd: piixpm0: 24-bit timer
Nov  3 15:37:33 Riffel /netbsd: piixpm0: interrupting at SMI, polling
Nov  3 15:37:33 Riffel /netbsd: iic0 at piixpm0: I2C bus
Nov  3 15:37:33 Riffel /netbsd: iic0: devices at 0x09 0x2d
Nov  3 15:37:33 Riffel /netbsd: lm_probe: rv = 1, cr = 1
Nov  3 15:37:33 Riffel /netbsd: lm0 at iic0 addr 0x2d
Nov  3 15:37:33 Riffel /netbsd: wb_match: winbond vend id 0x12c3
Nov  3 15:37:33 Riffel /netbsd: wb_match: winbond chip id 0x31
Nov  3 15:37:33 Riffel /netbsd: lm0: Winbond AS99127F Hardware monitor

now. I noted that taking out the DEBUG* options keeps the kernel from
recognizing the device?

        hauke


--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Hauke Fath-2]

At 15:48 Uhr +0100 03.11.2009, Hauke Fath wrote:
>I noted that taking out the DEBUG* options keeps the kernel from
>recognizing the device?

Just leaving in

options I2C_SCAN
lm* at iic? addr 0x2d

results in

[...]
piixpm0: interrupting at SMI, polling
iic0 at piixpm0: I2C bus
iic0: devices at 0x09 0x2d
lm0 at iic0 addr 0x2d
lm0: Winbond AS99127F Hardware monitor
[...]

and

# envstat
               Current  CritMax  CritMin  CritCap     Unit
[lm0]
   VCore A:      2.064                                   V
   VCore B:      2.512                                   V
     +3.3V:      3.648                                   V
       +5V:      5.053                                   V
      +12V:     11.856                                   V
      -12V:    -11.126                                   V
       -5V:     -5.153                                   V
     Temp0:     33.000                                degC
     Temp1:      0.000                                degC
     Temp2:      0.000                                degC
      Fan0:       3341                                 RPM
      Fan1:        N/A
      Fan2:        N/A
#

        hauke

--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Hauke Fath-2]

At 9:43 Uhr -0800 03.11.2009, Paul Goyette wrote:
>Just curious, can you try 'mbmon -S' to see if that's how it is
>getting its data?

Looks very similar, apart from Temp1:

# mbmon -S

Temp.= 33.0, 33.0,  0.0; Rot.= 3341,    0,    0
Vcore = 2.06, 2.51; Volt. = 3.65, 5.05, 11.80, -11.29, -5.14
^C
# envstat
               Current  CritMax  CritMin  CritCap     Unit
[lm0]
   VCore A:      2.064                                   V
   VCore B:      2.512                                   V
     +3.3V:      3.648                                   V
       +5V:      5.053                                   V
      +12V:     11.795                                   V
      -12V:    -11.126                                   V
       -5V:     -5.153                                   V
     Temp0:     33.000                                degC
     Temp1:      0.000                                degC
     Temp2:      0.000                                degC
      Fan0:       3341                                 RPM
      Fan1:        N/A
      Fan2:        N/A
#


>I'm suspecting that there's some contention between the piixpm i2c
>driver and ACPI's SMBus accessing the same bus.  This can cause all
>sorts of issues.
>
>I've written a ACPI SMBus i2c driver to use ACPI access directly,
>but it requires manually disabling the "native" i2c drivers since
>there's no clean way to prevent simultaneous access.  Perhaps you
>might want to try my driver to see if you get more consistent and
>reliable results?  (See attachment.)

I'll give that a try tomorrow.

        hauke

--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Paul Goyette]

On Tue, 3 Nov 2009, Hauke Fath wrote:

> At 9:43 Uhr -0800 03.11.2009, Paul Goyette wrote:
>> Just curious, can you try 'mbmon -S' to see if that's how it is
>> getting its data?
>
> Looks very similar, apart from Temp1:
>
> # mbmon -S
>
> Temp.= 33.0, 33.0,  0.0; Rot.= 3341,    0,    0
> Vcore = 2.06, 2.51; Volt. = 3.65, 5.05, 11.80, -11.29, -5.14
> ^C
> # envstat
>              Current  CritMax  CritMin  CritCap     Unit
> [lm0]
>  VCore A:      2.064                                   V
>  VCore B:      2.512                                   V
>    +3.3V:      3.648                                   V
>      +5V:      5.053                                   V
>     +12V:     11.795                                   V
>     -12V:    -11.126                                   V
>      -5V:     -5.153                                   V
>    Temp0:     33.000                                degC
>    Temp1:      0.000                                degC
>    Temp2:      0.000                                degC
>     Fan0:       3341                                 RPM
>     Fan1:        N/A
>     Fan2:        N/A
> #

Yeah, than confirms that mbmon is using SMBus access.

>> I'm suspecting that there's some contention between the piixpm i2c
>> driver and ACPI's SMBus accessing the same bus.  This can cause all
>> sorts of issues.
>>
>> I've written a ACPI SMBus i2c driver to use ACPI access directly,
>> but it requires manually disabling the "native" i2c drivers since
>> there's no clean way to prevent simultaneous access.  Perhaps you
>> might want to try my driver to see if you get more consistent and
>> reliable results?  (See attachment.)
>
> I'll give that a try tomorrow.

Great!  Make sure you remove 'iic* at piixpm?' from your config.


-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------

[Hauke Fath-2]

Paul Goyette wrote:

> On Tue, 3 Nov 2009, Hauke Fath wrote:
>
>> At 9:43 Uhr -0800 03.11.2009, Paul Goyette wrote:
>>> Just curious, can you try 'mbmon -S' to see if that's how it is
>>> getting its data?
>>
>> Looks very similar, apart from Temp1:
>>
>> # mbmon -S
>>
>> Temp.= 33.0, 33.0,  0.0; Rot.= 3341,    0,    0
>> Vcore = 2.06, 2.51; Volt. = 3.65, 5.05, 11.80, -11.29, -5.14
>> ^C
>> # envstat
>>              Current  CritMax  CritMin  CritCap     Unit
>> [lm0]
>>  VCore A:      2.064                                   V
>>  VCore B:      2.512                                   V
>>    +3.3V:      3.648                                   V
>>      +5V:      5.053                                   V
>>     +12V:     11.795                                   V
>>     -12V:    -11.126                                   V
>>      -5V:     -5.153                                   V
>>    Temp0:     33.000                                degC
>>    Temp1:      0.000                                degC
>>    Temp2:      0.000                                degC
>>     Fan0:       3341                                 RPM
>>     Fan1:        N/A
>>     Fan2:        N/A
>> #
>
> Yeah, than confirms that mbmon is using SMBus access.
>
>>> I'm suspecting that there's some contention between the piixpm i2c
>>> driver and ACPI's SMBus accessing the same bus.  This can cause all
>>> sorts of issues.
>>>
>>> I've written a ACPI SMBus i2c driver to use ACPI access directly,
>>> but it requires manually disabling the "native" i2c drivers since
>>> there's no clean way to prevent simultaneous access.  Perhaps you
>>> might want to try my driver to see if you get more consistent and
>>> reliable results?  (See attachment.)
>>
>> I'll give that a try tomorrow.
>
> Great!  Make sure you remove 'iic* at piixpm?' from your config.

Hm. Applied to HEAD sources, most of the man page patches fail. The
source patches apply, but I get

  --- cleanprog ---
rm -f a.out [Ee]rrs mklog core *.core .gdbinit
/public/netbsd-developer/sys/dev/acpi/files.acpi:153: syntax error
/public/netbsd-developer/sys/dev/acpi/files.acpi:155: syntax error
/public/netbsd-developer/sys/dev/acpi/files.acpi:156: syntax error
/public/netbsd-developer/sys/dev/acpi/files.acpi:157: syntax error
/public/netbsd-developer/sys/arch/i386/conf/files.i386: device
`acpismbus' used but not defined
*** Stop.

        hauke


--
      The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email        Institut fu"r Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf [phone]

[Paul Goyette]

On Wed, 4 Nov 2009, Hauke Fath wrote:

> Hm. Applied to HEAD sources, most of the man page patches fail. The source
> patches apply, but I get
>
> --- cleanprog ---
> rm -f a.out [Ee]rrs mklog core *.core .gdbinit
> /public/netbsd-developer/sys/dev/acpi/files.acpi:153: syntax error
> /public/netbsd-developer/sys/dev/acpi/files.acpi:155: syntax error
> /public/netbsd-developer/sys/dev/acpi/files.acpi:156: syntax error
> /public/netbsd-developer/sys/dev/acpi/files.acpi:157: syntax error
> /public/netbsd-developer/sys/arch/i386/conf/files.i386: device `acpismbus'
> used but not defined
> *** Stop.

Weird.  I just did a 'cvs update' to HEAD and all the patches applied
cleanly.  I build a TEST kernel from the following config:

  include         "arch/i386/conf/GENERIC"

  no iic* at viapcib?
  no iic* at ichsmb?
  no iic* at nfsmb?
  no iic* at piixpm?                      # SMBus on PIIX4

  acpismbus*      at acpi?
  iic*            at acpismbus?
  lm*             at iic? addr 0x2d

And it built successfully.  You should be able to retrieve it from

  ftp://ftp.whooppee.com/public/netbsd-i386-TEST.gz

After unzipping it, you can verify the checksum:

  SHA1 (netbsd-i386-TEST) = e22bf12a21c324c42fe8971fdc9c51cf312e6280


-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------