Powerd and est / eist functionality

[Jeremy Chadwick]

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 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 |