Date: Fri, 12 Sep 2008 20:36:17 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Jeremy Chadwick <koitsu@FreeBSD.org> Cc: FreeBSD stable <freebsd-stable@freebsd.org>, Richard Tector <richardtector@thekeelecentre.com> Subject: Re: Any working ichsmb(4) platforms out there? Message-ID: <48CAC4B1.6030108@FreeBSD.org> In-Reply-To: <48CAAB1A.9070502@incunabulum.net> References: <48C927DC.6000202@incunabulum.net> <48C932D9.50604@thekeelecentre.com> <48C934D1.5030703@incunabulum.net> <48C93582.3080107@thekeelecentre.com> <48C93903.5060604@protected-networks.net> <20080912072037.GC49512@icarus.home.lan> <48CAAB1A.9070502@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 00000001 %%% 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 00000001 %%% 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. cheers BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48CAC4B1.6030108>