From owner-freebsd-stable@FreeBSD.ORG Tue Jan 22 13:47:25 2008 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 CA63116A419; Tue, 22 Jan 2008 13:47:25 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id ACF0913C47E; Tue, 22 Jan 2008 13:47:25 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 672541CC031; Tue, 22 Jan 2008 05:47:25 -0800 (PST) Date: Tue, 22 Jan 2008 05:47:25 -0800 From: Jeremy Chadwick To: Gerrit =?iso-8859-1?Q?K=FChn?= Message-ID: <20080122134725.GA68722@eos.sc1.parodius.com> References: <20080121171606.8eb5f189.gerrit@pmp.uni-hannover.de> <20080121170102.GA46419@eos.sc1.parodius.com> <20080122094756.2d8f0bdf.gerrit@pmp.uni-hannover.de> <20080122092455.GA64519@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080122092455.GA64519@eos.sc1.parodius.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: T7200 CPU not detected by est 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: Tue, 22 Jan 2008 13:47:26 -0000 On Tue, Jan 22, 2008 at 01:24:55AM -0800, Jeremy Chadwick wrote: > I believe the problem is that our CPUs don't match any of the > identification verification methods performed in > src/sys/i386/cpufreq/est.c. > > I should be able to make a patch for this, but will need time -- our > to-be-dev/test C2D box sits in my living room waiting for CPUs to arrive > so it can be built. :-) I've spent most of this evening poking at the code in question, as well as looking at [too many] Intel specification documents for both the Intel Core 2 Duo Desktop (Exxxx) and Mobile (Txxxx) processors. Some technical details are below, followed by the "i'm a user not a programmer" stuff. The message "CPU supports Enhanced Speedstep, but is not recognized" is indeed because the E6420 and the T7200 are not in the frequency tables within src/sys/i386/cpufreq/est.c. It appears that est.c is actually for the older Pentium M and VIA Centaur platforms -- particularly, those which do not offer frequency tables via ACPI, and instead use some hard-coded tables based on CPU manufacturer specifications. However, within docs for the Intel C2D CPUs, the tables in question are no where to be found. You can find lots of documentation describing what all the VID bits do and what multiplication factor they break down to (e.g. 1.0000 = normal, 0.8250 = slower, 0.6000 = even slower, etc.) but there's no pre-defined list of frequencies that I could find. This frustrated me, so I took a look at what Linux did. Seems they were in the same boat, and ended up doing essentialy what FreeBSD has done: support SpeedStep on platforms which don't provide frequency tables through ACPI ("speedstep-centrino") and instead require fiddling of bits via MSR, and also support SpeedStep on platforms which have frequency tables provided via ACPI. They combined both drivers into a single driver, "speedstep-cpufreq", which prefers the ACPI method but will restort to the old MSR method on platforms where available: http://osdir.com/ml/kernel.cpufreq/2006-09/msg00004.html Further research into the FreeBSD side of things showed me that the cpufreq(4) driver supports both the MSR method (via est.c) and the ACPI method. This can be seen in the cpufreq(4) manpage; the MSR method is "est" (which is what est.c is), and the ACPI method is "acpi_perf". There's also "acpi_throttle", but I'm not sure what that is. cpufreq(4) provides both some kernel API functions for twiddling of stuff, as well as sysctl(8) knobs. That said, I did a `sysctl -a | grep freq` on our E6420 system with EIST enabled, and found the following relevant data: dev.cpu.0.freq: 2117 dev.cpu.0.freq_levels: 2117/-1 1852/-1 1587/-1 1323/-1 1058/-1 793/-1 529/-1 264/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 The dev.cpu.0.freq_levels values are CPU MHz/milliwatt; the -1 values for milliwatt are missing, but this shouldn't impact things. Since cpufreq(4) is what obtains these via ACPI (a la acpi_perf, I assume), it's safe to say that cpufreq(4) will slow the system down if one was to change dev.cpu.0.freq to one of the values shown in freq_levels. I have some ideas as to why there's no dev.cpu.1.freq, but my ideas are based on the older EIST stuff I've read tonight. That said: powerd(8) on FreeBSD will flip through all of the above MHz values, depending upon how you tune it. I use powerd(8) on my AMD Athlon 64 X2 system at home. I had to enable the Cool'n'Quiet BIOS option, and then this showed up: cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 icarus# ps -auxwwww | grep powerd root 669 0.0 0.0 3140 832 ?? Ss Thu06am 0:16.23 /usr/sbin/powerd -p 2000 And the sysctl values: dev.cpu.0.freq: 1005 dev.cpu.0.freq_levels: 2010/89000 1809/84600 1005/40100 dev.powernow.0.freq_settings: 2010/89000 1809/84600 1005/40100 dev.powernow.1.freq_settings: 2010/89000 1809/84600 1005/40100 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 Interesting thing here is that there's dev.powernow.[0].freq_settings while on the E6420 box there's only the 0 index. Anyway, I decided to run powerd on the EIST box to see what happened: # ps -auxw | grep powerd root 25602 0.0 0.0 3120 820 ?? Ss 5:43AM 0:00.00 /usr/sbin/powerd -p 2000 root 25604 0.0 0.0 1588 780 p1 R+ 5:43AM 0:00.00 grep powerd # sysctl -a | egrep 'dev.*freq:|freq_levels:' dev.cpu.0.freq: 1323 dev.cpu.0.freq_levels: 2117/-1 1852/-1 1587/-1 1323/-1 1058/-1 793/-1 529/-1 264/-1 # sysctl -a | egrep 'dev.*freq:|freq_levels:' dev.cpu.0.freq: 264 dev.cpu.0.freq_levels: 2117/-1 1852/-1 1587/-1 1323/-1 1058/-1 793/-1 529/-1 264/-1 And I can tell the system is significantly "slower" when idle, which is normal. :-) So give that a try... -- | 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 |