New nfpm.c driver available for testing

Ruslan Ermilov ru at
Tue Dec 20 23:54:47 PST 2005

On Tue, Dec 20, 2005 at 09:12:27AM +0300, Artemiev Igor wrote:
> I've recompiled your  nfm with CFLAGS+=-DDEBUG.
You'd better try the next version, but it works the same for

> ai at home$sudo ./smbtest /dev/smb0
> found slave device 8
> found slave device 80
> found slave device 82

> ai at home$sudo ./smbtest /dev/smb1
> found slave device 8
> found slave device 45
> found slave device 55
> found slave device 72
> found slave device 73
> found slave device 97
> found slave device 127

> smbtest gives me only a garbage.
What do you mean?  It found "SMBus host" (device 8) and some others.

> When I tried mbmon without -
> DSMBUS_IOCTL, it worked with SMBus through the /dev/io and "detected"
> slave address for the first smb controller as 0x5a
This is the shifted address, try "mbmon -A -D", it will display
both shifted and real slave device addresses, like this:

# ./mbmon -S -D
Probe Request: none
>>> Testing Reg's at SMBus <<<
 SMBus slave 0xA0(0x50) found...
 SMBus slave 0xA2(0x51) found...
SMBus[NVidia nForce2] found, but No HWM available on it!!
InitMBInfo: Device not configured

> Then I've run mbmon -A -d.
> It didn't find any sensors, but here is the driver's debug message:
> Dec 19 22:17:57 home kernel: nfpm: STS=0x10
> Dec 19 22:17:57 home kernel: nfpm: READB from 0x10, cmd=0x40, byte=0x0,

> Well, It's a  "Device Address Not Acknowledged" error.

> If I shift the
> slave address for reading, it works, and status register contains 0x80.
mbmon already shifts it, and our smb(4) is dumb in that it expects
the address already shifted.  (Linux does better here.)

> Yet, for writing I still have an 0x10.
In my case, I have (note that all addresses are even because
they are already "<< 1" shifted by mbmon).

nfsmb: READB from 0x9e, cmd=0x0, byte=0xff, error=0x4
nfsmb: STS=0x10
nfsmb: READB from 0xa0, cmd=0x0, byte=0x80, error=0x0
nfsmb: STS=0x0
nfsmb: READB from 0xa2, cmd=0x0, byte=0x80, error=0x0
nfsmb: STS=0x0
nfsmb: READB from 0xa4, cmd=0x0, byte=0xff, error=0x4
nfsmb: STS=0x10

(I only copied cmd=0x0.)  This corresponds to shifted addresses
0xa0 and 0xa2 (devices 0x50 and 0x51).

> The documentation for AMD-8111
> controller explains this by not-reset operational status before the
> controller checks the address.
Yes, AMD-8111 is another story.  It uses EC-based access to SMBus
registers, while nForce2/3/4 appear to provice I/O based SMBus
register access, and that matches the following info from lm-sensors:

# Notes
# -----
# The SMBus adapter in the nForce2/3/4 chipset seems to be very similar to the
# SMBus 2.0 adapter in the AMD-8111 southbridge. However, I could only get the
# driver to work with direct I/O access, which is different to the EC interface
# of the AMD-8111.
# Tested on Asus A7N8X. The ACPI DSDT table of the Asus A7N8X lists two SMBuses,
# both of which are supported by this driver.

> Btw, why in nfpm_wait you're polling SMB_PRTCL instead of SMB_STS? 
Because that's what the ACPI spec says to do, see section 12.9 of
the ACPI 3.0 spec.  (ACPI 2.0c spec is similar.)

I've solved the problem with using non-standard BARs, and will update
the patch shortly.  The PEC (Parity Error Checking) is not supported;
we'd need to grow the support for it in smb(4) first.

Ruslan Ermilov
ru at
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-current mailing list