From owner-freebsd-stable@FreeBSD.ORG Wed Mar 24 21:36:56 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 7B5DC106566B for ; Wed, 24 Mar 2010 21:36:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 608358FC12 for ; Wed, 24 Mar 2010 21:36:55 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta08.emeryville.ca.mail.comcast.net with comcast id x7FF1d00A1smiN4A89cwyd; Wed, 24 Mar 2010 21:36:56 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id x9cv1d00c3S48mS8g9cwFn; Wed, 24 Mar 2010 21:36:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8C0EA9B436; Wed, 24 Mar 2010 14:36:54 -0700 (PDT) Date: Wed, 24 Mar 2010 14:36:54 -0700 From: Jeremy Chadwick To: John Long Message-ID: <20100324213654.GA44288@icarus.home.lan> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.2.20100324100236.0320fec8@mail.sstec.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Nenhum_de_Nos 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: Wed, 24 Mar 2010 21:36:56 -0000 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. > 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. 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. If low-as-possible TDP is all you're concerned with, buy an Atom. > 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. 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 > 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 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. -- | 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 |