Powerd and est / eist functionality

[Jeremy Chadwick]

On Sat, Mar 27, 2010 at 04:51:49PM -0700, John Long wrote:
> At 02:14 AM 3/26/2010, Jeremy Chadwick wrote:
> >I'm willing to make an exception here.  If you can get the following
> >information from the motherboard manufacturer, I'd be willing to add
> >support for your board to bsdhwmon.  What I need:
>
> {snip}
>
> >3) What the SMBus slave address is they chose for the H/W IC
> 
> % dmesg | grep -i smbus
> pci0: <serial bus, SMBus> at device 31.3 (no driver attached)

All this means is that there's a SMBus-class device sitting on the PCI
bus which has no driver attached to it.  Run "pciconf -lvc" and find the
device in question, and the output relevant to it.

Given the topic of discussion, I'd say your northbridge is Intel-based,
which means you need the smb, smbus, and ichsmb drivers loaded.  You can
load these as kernel modules as well.  When loading them, do not specify
the trailing ".ko".  See the ichsmb(4) man page for some terse details.

Even if you get a driver attached to the SMBus piece of the northbridge,
like I said, there's no guarantee there's a H/W monitoring IC that's
wired to the SMBus.  As stated, I don't believe in probing slave
addresses on the SMBus, so the slave address would have to come from
Gigabyte, or...

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.

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.

> >> It jumped up in vcore a little there with powerd. C1E and C2E which
> >> include P-states are what I am really after and I think that the
> >> bios by itself provides those changes better than any other changes
> >> in these settings.
> >
> >...and this would fall under the est(4) subset driver for cpufreq(4).
> 
> This repeated clue got me to the next step and I thank you for that.
> The key, as I see it, is to get est working either by getting the
> msr tables updated somehow or getting the acpi working better so est
> could fall back on it therefore powerd would have a better set of
> signals to use rather than thermal. Like I have mentioned elsewhere,
> it looks like est has not really been updated nor worked on much for
> about 5 years and is missing the proper tables for the mbds since.
> That is a big and near impossible job unless it can be modded to a
> sort of wildcard detection if there is some commonality to newer
> mbds.

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:

CPU1 Temperature           41 C
System Temperature         36 C
FAN1                        0 RPM
FAN2                        0 RPM
FAN3                        0 RPM
FAN4                     1988 RPM
FAN5                     1532 RPM
FAN6                     1809 RPM
VcoreA                  1.220 V
MCH Core                1.514 V
-12V                  -11.904 V
V_DIMM                  1.712 V
+3.3V                   3.360 V
+12V                   12.000 V
5Vsb                    5.118 V
5VDD                    5.022 V
P_VTT                   1.140 V
Vbat                    3.312 V

And relevant sysctls:

debug.cpufreq.verbose: 0
debug.cpufreq.lowest: 0
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.1.%driver: cpufreq
dev.cpufreq.1.%parent: cpu1

dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.temperature: 41.0C
dev.cpu.0.freq: 2000
dev.cpu.0.freq_levels: 3000/35000 2667/28000 2333/22000 2000/16000
dev.cpu.0.cx_supported: C1/0 C2/85
dev.cpu.0.cx_lowest: C2
dev.cpu.0.cx_usage: 49.99% 50.00% last 286us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.temperature: 41.0C
dev.cpu.1.cx_supported: C1/0 C2/85
dev.cpu.1.cx_lowest: C2
dev.cpu.1.cx_usage: 49.99% 50.00% last 286us

dev.est.0.%desc: Enhanced SpeedStep Frequency Control
dev.est.0.%driver: est
dev.est.0.%parent: cpu0
dev.est.0.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000
dev.est.1.%desc: Enhanced SpeedStep Frequency Control
dev.est.1.%driver: est
dev.est.1.%parent: cpu1
dev.est.1.freq_settings: 3000/35000 2667/28000 2333/22000 2000/16000

The temperatures you see above are accurate, since it's a system I have
at home where I prefer quiet, low-speed fans.  :-)

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").

Since upgrading those boxes to RELENG_8, I've been able to re-enable
both BIOS options and use cpufreq(4) with est + powerd without any sign
of what I witnessed on RELENG_7.  Of course, I did that only a few days
ago, so it may be too soon to tell.

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