From owner-freebsd-stable@FreeBSD.ORG Fri Sep 12 19:36:19 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E18CC1065671; Fri, 12 Sep 2008 19:36:19 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id A2FDD8FC12; Fri, 12 Sep 2008 19:36:19 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 3014F1600F9; Fri, 12 Sep 2008 15:36:19 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 12 Sep 2008 15:36:19 -0400 X-Sasl-enc: 7mzCUtjagyzKimnJxQ/9p3ytXSBpM4d1Pzl9iA3dOjuE 1221248178 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6DFCA17649; Fri, 12 Sep 2008 15:36:18 -0400 (EDT) Message-ID: <48CAC4B1.6030108@FreeBSD.org> Date: Fri, 12 Sep 2008 20:36:17 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Jeremy Chadwick 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> In-Reply-To: <48CAAB1A.9070502@incunabulum.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD stable , Richard Tector Subject: Re: Any working ichsmb(4) platforms out there? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2008 19:36:20 -0000 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: port 0x5000-0x500f at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: 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