From owner-freebsd-stable@FreeBSD.ORG Sun Mar 28 00:43:00 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 84BCA106567B for ; Sun, 28 Mar 2010 00:43:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 25C0E8FC1E for ; Sun, 28 Mar 2010 00:42:59 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id yQgh1d0021vXlb85DQj0LS; Sun, 28 Mar 2010 00:43:00 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.westchester.pa.mail.comcast.net with comcast id yQmy1d00A3S48mS3dQmygA; Sun, 28 Mar 2010 00:46:59 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3A1FA9B436; Sat, 27 Mar 2010 17:42:57 -0700 (PDT) Date: Sat, 27 Mar 2010 17:42:57 -0700 From: Jeremy Chadwick To: John Long Message-ID: <20100328004257.GA52623@icarus.home.lan> References: <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <1269310984.00232724.1269300005@10.7.7.3> <1269310984.00232724.1269300005@10.7.7.3> <5.2.1.1.2.20100324134153.032459d8@mail.sstec.com> <5.2.1.1.2.20100325235505.031e8338@mail.sstec.com> <5.2.1.1.2.20100327152415.0320bf28@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.20100327152415.0320bf28@mail.sstec.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alexander Motin , FreeBSD-STABLE Mailing List , Ian Smith 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: Sun, 28 Mar 2010 00:43:00 -0000 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: 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@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |