Powerd and est / eist functionality

[John Long]

At 02:14 AM 3/26/2010, Jeremy Chadwick wrote:
 >On Fri, Mar 26, 2010 at 01:20:19AM -0700, John Long wrote:
 >> >Yes you're only getting p4tcc throttling as Alexander points out. You'll
 >> >need to get est working to get power reduction from lower frequencies,
 >> >which likely won't correspond to these f/8 step throttling frequencies.
 >> >
 >> >As Jeremy suggested, here's how to turn throttling off, and something
 >> >like what you could expect with est working:
 >> >http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html
 >>
 >> from link:
 >> I would recommend you to disable it by setting:
 >> hint.p4tcc.0.disabled=1
 >> hint.acpi_throttle.0.disabled=1
 >>
 >> I get unknown oid on both. Not sure how to disable p4tcc here. What
 >> I have to work with.
 >
 >These are /boot/loader.conf tunables, not sysctl.  I'm pretty sure I
 >stated that in my previous mail...?

Drats, you are right. too late at night.. did not give me anything positive 
anyway.
 >
 >> Bios is most recent, has EIST, c1e and c2e I believe enabled. That
 >> seems to do the best all by itself. Maybe It does no good to beat a
 >> dead horse?? :-)  I see an ITE IT8718F-S chip on board. mbmon does
 >> work somewhat but its code is way old and does not see the newer
 >> chip versions. some good docs with mbmon in usr/local/share/docs
 >> tho..
 >> %mbmon -d -A
 >> Summary of Detection:
 >>  * ISA monitor(s):
 >>   ** Nat.Semi.Con. Chip LM78 found.
 >>   ** Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950 found
 >>
 >
 >Ignore all of the above values -- mbmon doesn't work properly with your
 >board, or that sub-revision of IT chip.  It's that simple.  Re-read the
 >rant I sent you for explanation; I already covered all the bases.  :-) I
 >disagree about the mbmon docs -- they're more like chaotic brain dumps
 >or scribbled notes than actual coherent, well-written instructions or
 >details.

Agreed, but they were something vs not much and I was grasping :-)

  That said, I have utmost respect for SHIMIZU Yoshifumi and his
 >efforts/work.
 >
 >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:
 >
 >1) The exact H/W monitoring IC they use (not what mbmon says, and
 >   not what's silkscreened on the chip),

That would be a bit impossible for me, what is on the chip is all I can 
provide.
 >
 >2) If the H/W monitoring IC is tied in to SMBus,

hellava question too, Tell me and we would both know :-)
 >
 >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)

I am pretty sure I would get a deer in the headlights response from 
gigabyte over this question..

 >
 >4) Output of "kenv | grep smbios" from your system.
 > kenv | grep smbios

smbios.bios.reldate="11/04/2009"
smbios.bios.vendor="Award Software International, Inc."
smbios.bios.version="F6"
smbios.chassis.maker="Gigabyte Technology Co., Ltd."
smbios.chassis.serial=" "
smbios.chassis.tag=" "
smbios.chassis.version=" "
smbios.memory.enabled="1048576"
smbios.planar.maker="Gigabyte Technology Co., Ltd."
smbios.planar.product="G41M-ES2L"
smbios.planar.serial=" "
smbios.planar.version="x.x"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="Gigabyte Technology Co., Ltd."
smbios.system.product="G41M-ES2L"
smbios.system.serial=" "
smbios.system.uuid="00000000-0000-0000-0000-6cf049635a47"
smbios.system.version=" "
smbios.version="2.4"

1 out of 4 is not too bad :-)
 >
 >Assuming all of the above meets necessary criteria, I can probably add
 >support for this board to bsdhwmon.  I have only slight qualms/concerns
 >adding consumer boards to bsdhwmon, but the big kicker is that the board
 >**must** have an actual H/W monitoring IC tied/wired to SMBus.  I *will
 >not* use the old LPC/ISA (/dev/io) infrastructure.

I understand, there are just too many possible different implementations 
and chips being used. Getting Vcore from both healthd and mbmon, being 
about the same and that being the main concern for my discovery into 
functionality has me satiated. Getting the rest of the sensors would be 
great but certainly would not be worth any effort from you or anyone for 
just this one of hundreds of mbds. I do appreciate the offer tho. I should 
of bought Asus in the first place. I always have for past 12 years but my 
selection dwindled about 3 weeks ago when Frys dropped the asus p5qpl-am. 
That was the only non realtek ether g41 mbd I could find. I took a chance 
that the re8111 (gigabyte and most others) drivers would work as well and 
it looks like they do. The only remaining viable asus mbd, to me, is the 
p5g41-m lx2/gm but a search on asus's site and it is not to be found 
therefore that would be a nono for me.
There are just too many different mbds out there, the manufs have just gone 
hog wild.

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

John

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