Date: Wed, 24 Mar 2010 18:04:51 -0700 From: John Long <fbsd2@sstec.com> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org, Nenhum_de_Nos <matheus@eternamente.info> Subject: Re: Powerd and est / eist functionality Message-ID: <5.2.1.1.2.20100324165115.03159ab8@mail.sstec.com> In-Reply-To: <20100324213654.GA44288@icarus.home.lan> References: <5.2.1.1.2.20100324100236.0320fec8@mail.sstec.com> <5.2.1.1.2.20100322150534.032bee30@mail.sstec.com> <5.2.1.1.2.20100322150534.032bee30@mail.sstec.com> <5.2.1.1.2.20100324100236.0320fec8@mail.sstec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:36 PM 3/24/2010, Jeremy Chadwick wrote:
>On Wed, Mar 24, 2010 at 01:37:06PM -0700, John Long wrote:
>> I am trying to ascertain the viability of this motherboard w/
>> regards to getting the power function working proper and am
>> constrained by the lack of monitoring tools vs what cupid.com has
>> for win with hwmonitor and cpuz (they have a dev kit also). Would
>> another brand/model of mb work better? I know that most all are
>> lacking in acpi function in diff ways. Maybe I am squeezing water
>> out of a rock, that the cpu is at its min or 6 watts now, but I just
>> do not know.
>
>You're placing too many eggs in one basket. Hardware monitoring is a
>separate beast, and one you won't find good support for on FreeBSD.
>By "hardware monitoring" I'm talking about thermals off the mainboard,
>fan RPMs, CPU temperature (not on-die temps), and voltages. Let's talk
>about those first, as they're something I'm familiar with.
>
>- These data sources are only available if the motherboard manufacturer
>added a H/W monitoring I/C to their mainboard. Consumer mainboards
>are spotty as far as offering this capability.
>
>- Each mainboard is different. Each mainboard model, or even
>subrevision, can use a completely different H/W monitoring chip. To
>make matters more complex, there are multiple models of H/W monitoring
>ICs, and even multiple revision/versions of the same model that behave
>completely different than their predecessor(s).
>
>- How this chip is implemented on the mainboard is up to the
>manufacturer. Some chips only exist on the LPC bus (think ISA I/O
>ports). Some chips support SMBus. The mainboard has to be engineered
>so that the pins on the H/W IC tie in to the LPC or SMBus bus(ses). You
>don't know which is available/used unless the manufacturer states such
>in their User Manual.
>
>- In the case of LPC, the exact I/O ports must be provided by the board
>manufacturer. In the case of SMBus, the slave address must be
>provided by the board manufacturer. **YOU CANNOT GUESS THESE** despite
>Linux's lm-sensors project having folks think otherwise. Guessing
>("probing") is very high risk, and involves submitting reads to a select
>set of LPC I/O ports (which could be used for other things/devices), or
>to a select SMBus slave address. Some registers do things to the system
>(or associated chips) on read operations; bits can get reset. I've seen
>this happen in the case of one Winbond chip where an incorrect CRxx read
>resulted in the chips' watchdog firing an NMI.
>
>- Knowing the exact model and subrevision of H/W IC is important, since
>programmer of the monitoring software has to know what all the
>register offsets are, how to decode the data, etc.. There is no
>standard, and there are multiple manufacturers of such devices
>(Nuvoton/Winbond, National Semiconductor, ON Semiconductor/Analog
>Devices, SMSC, TI, and some others. For a while companies like AMD,
>nVidia, Intel, Broadcom, ALi, and VIA were making their own chips as
>well).
>
>- In the case of SMBus, the operating system must have an SMBus driver
>for the system chipset (not H/W chip). For example, Intel systems often
>use ichsmb(4), AMD systems use amdsmb(4), and so on. Without a driver
>it's not feasible/possible for userland applications to talk to a device
>connected to SMBus. For sake of example, there's no SMBus driver on
>FreeBSD for ServerWorks chipsets.
>
>Getting all of this data out of the mainboard manufacturer is like
>pulling teeth, especially in the case of consumer boards. Server board
>manufacturers (Supermicro, Tyan, Intel, etc.) often disclose this
>information to those who request it via Technical Support. But if you
>were to mail, say, Asus for this information, it'd likely go in one ear
>and out the other.
>
>All that (negativity) said: the closest thing you'll find on FreeBSD to
>interface with these chips is ports/sysutils/mbmon,
>ports/sysutils/healthd, or ports/sysutils/bsdhwmon.
>
>mbmon supports very old mainboards which utilise LPC (it's SMBus support
>is broken/shoddy). It also tries auto-probing, often gets it wrong, and
>spits out readings which are incorrect/off the charts. Sometimes it
>gets things wrong and spits out values that look real but aren't.
>
>healthd is basically mbmon with some minor changes to the core but major
>changes to the surrounding user interface.
>
>bsdhwmon is intended for servers only and only speaks to devices using
>SMBus, of which I'm the author.
>
>Are we having fun yet?
>
>Now back to the bigger picture...
>
>CPU temperature (assuming you have a newer AMD or Intel CPU) is
>available via the coretemp(4) driver, and active CPU clock frequency is
>available via the cpufreq(4) drivers and their subsets. There is also
>some very archaic (IMHO) support for temperature monitoring via ACPI,
>but I believe that's mainly intended for laptops. With regards to ACPI,
>you're purely limited by what the mainboard/BIOS implementer does; many
>consumer motherboard vendors have absolutely no idea what to do with a
>technical support request asking they fix/improve their ACPI tables.
>
>For coretemp(4), you'll find the thermals under dev.cpu.X.temperature
>in sysctl.
>
>For cpufreq(4), you'll find the available processor frequency levels
>under dev.cpu.X.freq_levels and what the current frequency is in
>dev.cpu.X.freq.
>
>For est(4), there's dev.est.X.freq_settings but I'm not sure how to get
>these to be used or how to tune them; keep reading.
I want to thank you very much for all the info you have provided. It has
clued me into a much better understanding and I see that it is a big
un-standard thing to monitor these functions. It seems that things are
actually working well with this system and I am chasing diminishing returns.
Let me just add this link for others that are on a path of understanding re
eist/est/powerd etc..
http://www.techarp.com/showarticle.aspx?artno=420&pgno=1 All power states
defined and link to acpi docs.
>
>> Btw: Intel is blowing out all 775 type chips. Today is about the last
>> day. They want everyone on I3/I5 etc but they are not as functional re
>> low tdp as 775 chips.
>
>That's a very interesting opinion you have there. I continue to see
>LGA775 chips sold regularly all over, and new stock coming in fairly
>often to major resellers online.
Knowing of the problems with h55 and bsd etc while needing to update both
my servers (k6-3 antiques from 1998 plus I have to get ready for the DNSSEC
changeover coming soon - run my own dns), I have been trying to catch the
Frys specials for a couple months on the Eseries c2d mdb and chip combos. 2
weeks ago I caught the hint that they were blowing all 775 stuff out, Frys
employee verified that, Intel's orders. Frys is big, Intel is not making
anymore 775 chips and when they are gone then only few online will have it.
They are going fast, On Saturday Frys (Woodland hills) had 25 E7500s, they
had a E7500 and mbd sale on monday and another today. I doubt they have
anymore other than open box now. They blew out all other 775 chips they had
prior to monday (e3400 last wk, 6300 prior). They may have some Q or E8200
etc but they may have another sale if so. It will not be long before newegg
and others are out of stock and cost will go way up. They want to push
everyone into the I-series. Wait and see..
>
>The i3/i5/i7 chips don't appear to offer ECC framework on their memory
>controllers (which are now on-die as I'm sure you know), which is why I
>plan to stay away from them for servers. Intel's pushing Xeon for that,
>which I'm not willing to switch to until the prices drop more. There
>are existing C2D and C2Q CPUs which have the exact same capabilities and
>features as their Xeon counterparts yet the Xeons cost $50-100 more.
>It's like SCSI all over again.
>
I agree with your thoughts however I believe one can still use the I-series
in a p55 board and get the ECC working but then you need to use a separate
video bd and the TDP is going to be about 30+ watts higher than using a g41
or such mbd and 775 chip.
>If low-as-possible TDP is all you're concerned with, buy an Atom.
Atom is about half the perf of a c2d especially if c2d is oc'd. An Atom in
a gclf945 mbd is about 35 watts because of the old 945 chip is 130nm tech.
Atom in Nvidia mdb would be way to go but c2d is still much faster. I get
41 watts with E7500, G41 mbd w/ video, 1 GB mem and 1 TB WD cavier HD
including losses thru power supply (antec 380 green -80 plus bronze,
smallest 80 plus handy). 24/7/365 is $1.00 per watt at my current rate of
8.5c / KWhr per year. Save 20 watts is saving $20.00 or more per year plus
I am set up for running on batteries and going solar. Do not discount the
problems in the economy. I run a truth website (netctr.com), things are not
as we are told by tptb.
>
>> I can find very little comprehensive info on how the
>> eist/est//p4tcc/powerd thing is supposed to work. Reading source of
>> powerd is not helping. Logically, if the voltage is lowered then the
>> power is going to be lower. Is the voltage a function of the load
>> automatically controlled by hardware and/or the bios or is it
>> supposed to be an artifact of the freq being lowered by something
>> like powerd? I believe the former for the latter is not working. I
>> now have everything relevant in the bios enabled.
>
>What you probably want to look at is the source to all the subset
>cpufreq(4) drivers that powerd(8) speaks to. See the cpufreq(4) man
>page for details.
I followed that and quite a bit more, it looks to be too much for just I to
handle with my constraints of duty and time.
>
>It seems most of us here -- myself included -- have very little
>familiarity with how to get FreeBSD to use one subset driver or another
>(e.g. est(4) vs. acpi_throttle(4), etc.). Someone recently clued me in
>to how to switch from acpi_throttle to est on my Intel board which
>*does* attach est(4) successfully, but I haven't bothered trying it
>yet:
>
>http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055665.html
>http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/055666.html
>
>The disabled=1 variables shown there are for loader.conf, by the way,
>and require a reboot after adjusting.
>
>I'd give you links to the main thread, but Dan Naumov's mail client
>doesn't appear to have Reference-Id header support so every reply of
>his appears as a "new" entry in the thread list. Search for "powerd on
>8.0, is it considered safe?" here:
>
>http://lists.freebsd.org/pipermail/freebsd-stable/2010-March/thread.html
I read all that and much more for several years back in my archives (I keep
about 11 years of mailists in my system here). I figured it was a nebulous
quest without more info. Now I see it is more then I need to byte off :-)
>
>> est appears to be not working but what would happen if it were
>> working?
>
>It should lower the clock frequency of the CPU during idle times, and
>increase it during load. **HOW** it goes about adjusting the frequency
>is where the different subset drivers come into play.
>
>The attachment "error 6" message you see usually indicates the est(4)
>driver doesn't have support for you specific model of CPU based on its
>capabilities, or at least that's how I understand it. John Baldwin (I
>think?) or Nate Lawson might have to chime in here.
>
>You're not the first one to report this issue. It comes up fairly
>often. Possibly since you're digging into the code you'd like to take
>up maintaining these pieces?
I appreciate the offer but I think it is more than I can chew right now :-)
I was just trying to find out how all this was supposed to work in the proper.
>> I csupd to stable and rebuilt and there is no difference w/ this
>> prob. I did see that I went from SATA150 (it should be SATA300) to
>> udma100 sata but that is for another thread.
>
>This is a bug/quirk of some changes in ata(4). Your drive should be
>operating at full SATA speed (probably SATA300). You can bring this up
>in another thread if you want, but it's purely cosmetic as far as I
>know. atacontrol(8) and diskinfo(8) -t and -c will come in handy.
Moving this to another thread for there are some unknowns here.
>
>--
>| 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 |
Thanks much again,
John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.2.1.1.2.20100324165115.03159ab8>