Any working ichsmb(4) platforms out there?

Bruce M. Simpson bms at
Fri Sep 12 19:36:20 UTC 2008

Bruce M Simpson wrote:
> I fished out the A/Open MX3S board I have.
> So I can confirm SMBus works on the MX3S from Linux 2.6.x. I'll blow 
> it away with 7.1-BETA and see what happens next.

I can confirm that SMBus appears to work on the A/Open MX3S under 
FreeBSD 7.1-BETA.

After kldload ichsmb and kldload smb:
ichsmb0: <Intel 82801BA (ICH2) SMBus controller> port 0x5000-0x500f at 
device 31.3 on pci0
ichsmb0: [GIANT-LOCKED]
ichsmb0: [ITHREAD]
smbus0: <System Management Bus> on ichsmb0
smb0: <SMBus generic I/O> on smbus0

smbmsg -p:
Probing for devices on /dev/smb0:
Device @0x30: rw
Device @0x50: rw
Device @0xb0: rw
Device @0xd0: rw

pciconf -a seems to be broken:
raisin:~ % s pciconf -a pci0:0:31:3
pciconf: ioctl(PCIOCATTACHED): Inappropriate ioctl for device

My theory at the moment is that the working platforms might have had 
some other bits twiddled in PCI config space.

I'm ruling that out for now, based on the fact that when I dump the CSRs 
for the SMBus function on both the ICH2 (known good, working) and ICH7 
(suspect), the HOSTC register contents are the same (SMBus is enabled) 
and both have interrupt lines routed to them.

working system, ICH2:
raisin# pciconf -r pci0:0:31:3 0:0x40
24438086 02800001 0c050002 00000000
00000000 00000000 00000000 00000000
00005001 00000000 00000000 244b8086
00000000 00000000 00000000 0000020c

suspect system, ICH7:
foo:~ % s pciconf -r pci0:0:31:3 0:0x40
27da8086 02800001 0c050001 00000000
00000000 00000000 00000000 00000000
00000501 00000000 00000000 27da8086
00000000 00000000 00000000 00000213

Both are using SMP-enabled kernels. The working system is running a 
7.1-BETA kernel, GENERIC so it has SMP, but it's a uniprocessor 633MHz 
Celeron; the suspect system has dual-core (I *think* it is Intel Atom).

I'm not sure how that could make a difference. The ichsmb(4) driver uses 
msleep() (now deprecated) to avoid busy-waiting when polling for SMB 
transaction completion. On the suspect system, msleep() always times 
out. So both are using ithreads...

AHA! After a reboot it looks like I can see a device on the suspect 
system, interesting. But after the first probe, it doesn't respond.

This could well be down to the implementation of that particular SMBus 
device on the platform, and it tends to move the finger of suspicion 
away from the smbus drivers themselves.


More information about the freebsd-stable mailing list