Date: Tue, 22 Jan 2008 05:47:25 -0800 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Gerrit =?iso-8859-1?Q?K=FChn?= <gerrit@pmp.uni-hannover.de> Cc: freebsd-stable@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: T7200 CPU not detected by est Message-ID: <20080122134725.GA68722@eos.sc1.parodius.com> In-Reply-To: <20080122092455.GA64519@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <ACPI CPU> on acpi0
powernow0: <Cool`n'Quiet K8> on cpu0
cpu1: <ACPI CPU> on acpi0
powernow1: <Cool`n'Quiet K8> 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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080122134725.GA68722>