From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 19:42:04 2010 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 409CB1065689 for ; Sun, 28 Mar 2010 19:42:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 20BAB8FC1B for ; Sun, 28 Mar 2010 19:42:03 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta06.emeryville.ca.mail.comcast.net with comcast id yen01d0020S2fkCA6ji4mK; Sun, 28 Mar 2010 19:42:04 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta09.emeryville.ca.mail.comcast.net with comcast id yji31d00B3S48mS8Vji30i; Sun, 28 Mar 2010 19:42:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6D1279B436; Sun, 28 Mar 2010 12:42:02 -0700 (PDT) Date: Sun, 28 Mar 2010 12:42:02 -0700 From: Jeremy Chadwick To: John Long Message-ID: <20100328194202.GA76443@icarus.home.lan> References: <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <1269310984.00232724.1269300005@10.7.7.3> <1269310984.00232724.1269300005@10.7.7.3> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100327152415.0320bf28@mail.sstec.com> <5.2.1.1.2.20100327191554.031f6a50@mail.sstec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.2.20100327191554.031f6a50@mail.sstec.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alexander Motin , FreeBSD-STABLE Mailing List , Ian Smith Subject: Re: Powerd and est / eist functionality 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: Sun, 28 Mar 2010 19:42:04 -0000 On Sun, Mar 28, 2010 at 12:16:27AM -0700, John Long wrote: > At 05:42 PM 3/27/2010, Jeremy Chadwick wrote: > > put this in > # Intel Core/Core2Duo CPU temperature monitoring driver > device coretemp coretemp(4) will get you the temperatures of each processor core, provided via the dev.cpu.X.temperature sysctls. > %smbmsg -p > Probing for devices on /dev/smb0: > Device @0x10: w > > Does not look to be much there if I am doing this right.. smbmsg -p won't help here -- I've never seen it detect H/W ICs that sit on SMBus. In fact, on all my systems, it doesn't report anything exists on the slave address tied to the boards' Winbond chips. I have no idea what "probe modus" means (see smbmsg(8) man page) nor how the probe actually works behind the scenes. So, it's an ineffective way to get an answer to your dilemma. It would make more sense to run SpeedFan on Windows, see if it's able to find a chip via SMBus, and provide those details. Another alternative would be to try using lm-sensors on Linux, although I'm pretty sure lm-sensors prefers LPC/ISA mode (claiming "it's more stable and more reliable" -- whatever). I have no experience with this software, aside from occasionally having to dig through their spaghetti code to try and find details about chip quirks. > >There's a program for Windows (9x/2K/XP/Vista) called SpeedFan which > >does do probing and can/does support SMBus. I have no idea if it works > >on Windows 7 or not: > > > >http://www.almico.com/speedfan.php > > > >If SpeedFan shows you all the data you expect/want, and indicates it's > >talking to a H/W IC over SMBus, then I could add support for your board > >to bsdhwmon (since your motherboard does provide acceptable SMBIOS > >tables for identification). I'd still need to know what slave address > >the chip had, and what exact model of H/W IC it was. SpeedFan might > >provide that. > > I have a feeling that my smbus is just not hooked up, nothing > there.. speedfan looks cool tho. I don't know what you mean by "my smbus is just not hooked up". Your above 'device' additions to your kernel shows that FreeBSD is now able to talk to the SMBus interface on your northbridge. As stated, smbmsg isn't going to help determine what H/W IC is on your board (if any). I'll see if I can find a very high resolution photo of your motherboard and try to work out if any ASICs are used for H/W monitoring (these days such chips also often provide Super I/O support (floppy, LPT, COM, LPC/ISA, etc.)). I'll probably have to review the user manual. I'll report back once I do that. > >It would also help (me at least) if you could reboot your system, go > >into your BIOS and find whatever menu item is associated with Hardware > >Monitoring and write down all of the shown attributes and their values. > >What the BIOS shows is what should be accurate above all else. > > >I can point you to numerous present-day motherboards that work just fine > >with cpufreq(4) and est under RELENG_8, and also work when using > >acpi_throttle. Specifically, Supermicro PDSMi+, X7SBA, and X7SBL-L2 > >boards. I'm sure there are many others. In all of these are Core2Duo > >or Core2Quad CPUs. An example from the X7SBA system, running powerd: > > It looks good, all working.. Okay, but that doesn't help me any. :-) Can you please write down all the H/W monitoring attributes + values shown in the BIOS and provide them here? > >I should note that the device attachment error (error 6) is something > >I've seen on my PDSMi+ boards under RELENG_7 when EIST and C1 Enhanced > >Mode were disabled in the BIOS. FreeBSD would report that SpeedStep > >existed but that it wasn't able to attach. > > > >I *explicitly* disabled those features in the BIOS since I saw some > >bizarre process behaviour ("calcru: runtime went backwards ... for pid > >X"). > > Have you tried to measure the wall power with a kill-a-watt yet or > can you? I have a couple Kill-a-Watt devices, but I tend to not bother with them for tests of this nature since they don't provide enough granularity on the LCD (only 1 or 2 digits past the decimal point). I also find them to be finicky/unreliable -- for example, I hooked a residential home toaster up to a RackPDU (which provides amps and watts used via web + SNMP). Powering on the toaster showed an increase from 0.00 amps to 1.1 amps. Hooking the same toaster up to 2 separate Kill-a-Watt units returned the same result: 0.4 amps. I performed the same tests with a standard household fan (3-speed), and I saw similar readings (the Kill-a-Watt always appearing off by a pretty large amount). WRT all the systems I've applied cpufreq(4) + est + powerd to: they're all production. I'm not willing to power them down, go to the co-lo, hook up a Kill-a-Watt device, power them on, wait around for 30 minutes, etc.. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |