Date: Fri, 12 Sep 2008 00:20:37 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Michael Butler <imb@protected-networks.net> Cc: Bruce M Simpson <bms@incunabulum.net>, FreeBSD stable <freebsd-stable@freebsd.org>, Richard Tector <richardtector@thekeelecentre.com> Subject: Re: Any working ichsmb(4) platforms out there? Message-ID: <20080912072037.GC49512@icarus.home.lan> In-Reply-To: <48C93903.5060604@protected-networks.net> References: <48C927DC.6000202@incunabulum.net> <48C932D9.50604@thekeelecentre.com> <48C934D1.5030703@incunabulum.net> <48C93582.3080107@thekeelecentre.com> <48C93903.5060604@protected-networks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 11, 2008 at 11:28:03AM -0400, Michael Butler wrote: > Richard Tector wrote: > > Bruce M Simpson wrote: > >> Richard, > >> > >> Thanks for this. > >> > >> Richard Tector wrote: > >>> > >>> I have an ICH9 machine, Tyan motherboard: > >>> FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 > >>> ichsmb0: <SMBus controller> port 0x18e0-0x18ff mem > >>> 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 > >>> ichsmb0: [GIANT-LOCKED] > >>> ichsmb0: [ITHREAD] > >>> > >>> daffy# smbmsg -p > >>> Probing for devices on /dev/smb0: > >>> Device @0x2e: rw > >> ... > >> So it looks like yours works! I see no differences to RELENG_7_0. > >> > >> Are you using any hardware monitoring devices? > >> Can you give bsdhwmon a shot? > >> > >> cheers > >> BMS > > > > Sure. If yourself or Jeremy could send over the tarball? > > I don't use any hardware monitoring on it currently. > I'd also appreciate the opportunity to try it .. old hardware but .. > > imb@aaron:/home/imb> devinfo -v | grep smb > intsmb0 pnpinfo vendor=0x8086 device=0x7113 subvendor=0x0000 > subdevice=0x0000 class=0x068000 at slot=7 function=3 handle=\_SB_.PCI0.PMU_ > smbus0 > smb0 > imb@aaron:/home/imb> kenv | grep smbios > smbios.bios.reldate="07/20/2001" > smbios.bios.vendor="Intel Corp." > smbios.bios.version="TR440BXA.86B.0042.P15.0107200951" > smbios.chassis.maker="Dell Computer Corp. " > smbios.chassis.serial="YC571 " > smbios.chassis.tag=" " > smbios.chassis.version="SPAW70W PA[CA] " > smbios.planar.maker="Intel Corporation " > smbios.planar.product="TR440BXA " > smbios.planar.serial="IMTR02702003 " > smbios.planar.version="A16643-305 " > smbios.socket.enabled="1" > smbios.socket.populated="1" > smbios.system.maker="Dell Computer Corp. " > smbios.system.product="PowerApp.web 100 W " > smbios.system.serial="YC571 " > smbios.system.uuid="44454c4c-00ca-1059-8043-80c04f353731" > smbios.system.version="SPAW70W " didn't think anyone was still using Intel 440BX boards in this day and age! (A great chipset, though!) I can absolutely assure you bsdhwmon will not work on this board. I can add support for it, but I need to know full register details of what H/W monitoring IC is tied to SMBus, and what the SMBus slave address is of the monitoring IC. > imb@aaron:/home/imb> sudo smbmsg -p > Probing for devices on /dev/smb0: > Device @0x5a: rw > Device @0x60: rw > Device @0x62: rw > Device @0x64: rw > Device @0x66: rw > Device @0xa0: rw > Device @0xa2: rw > Device @0xa4: rw > Device @0xa6: rw > imb@aaron:/home/imb> sudo mbmon -d > Using SMBus-ioctl access method[IntelPIIX4(440BX/MX)]!! > * Analog Dev. Chip ADM9240 found. Can you confirm this is correct? Does this board really have an ADM H/W monitoring IC on it? Are the rpms/voltages/temps returned by mbmon *actually correct? Hardware monitoring software in the ports tree make some general assumptions over what the register offset/indexes are, which are often wrong depending upon what sub-model of chip is used. This is one reason why bsdhwmon reads the smbios data and matches motherboard model up with what chip is installed on the board. I'm sure I'll eventually encounter a situation where motherboard X has two different revisions of hardware monitoring ICs on it (e.g. one is a 1234A, and later releases of the same board use a 1234B), but the code should be able to account for that cleanly. The state of hardware monitoring on BSD is atrocious, and it was atrocious 10 years ago. Absolutely no evolution has occurred in this regard, while Linux's lm-sensors has pretty much dominated in this regard. OpenBSD has sensors framework, too. A user on #bsdports privately discussed this situation with me yesterday, as apparently there are a large number of Russian forums and mailing lists discussing how to get mbmon, consolehw, or healthd to work with their systems. What these people aren't aware of is how outdated the programs are, how it all works, and the risks involved when using a hardware monitor that blindly hits certain registers (this is especially risky with ISA bus interaction). I'm trying my best to make things better, doing things purely from a userland perspective and using SMBus exclusively (since the interface is quite reliable, assuming the SMBus driver used on FreeBSD is working correctly). I understand-- Bruce is having problems with ichsmb(4), while on every ICH7 board I have (and I have many), I've had nothing but success. All of bsdhwmon's main development has been done on ICH7 boards I use and have physical access to, for example. I wish I knew more about the inner-workings of PCI and SMBus in general, but as it stands, my knowledge is limited solely to interfacing with a device *on* the SMBus. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080912072037.GC49512>