Date: Wed, 10 Dec 2008 00:49:24 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Gabriel Lavoie <glavoie@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Intel Pentium Dual Core E5200 and Enhanced Speedstep Message-ID: <20081209233239.F94168@sola.nimnet.asn.au> In-Reply-To: <d05df8620812090416i6f0e0f0cx3f0b042ff7eaeab1@mail.gmail.com> References: <20081209030117.BDE66106575E@hub.freebsd.org> <20081209163440.J94168@sola.nimnet.asn.au> <d05df8620812090416i6f0e0f0cx3f0b042ff7eaeab1@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Dec 2008, Gabriel Lavoie wrote: > 2008/12/9 Ian Smith <smithi@nimnet.asn.au> > > On Mon, 8 Dec 2008 13:37:09 -0500 Gabriel Lavoie <glavoie@gmail.com> > > wrote: [ skipping lots until you've seen how powerd goes on it .. and please drop gmail's HTML attachments on messages to the FreeBSD lists] > [wildchild@headless ~]$ uname -a > FreeBSD headless.mutehq.net 7.0-RELEASE-p6 FreeBSD 7.0-RELEASE-p6 #0: Mon > Nov 24 10:59:10 UTC 2008 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Ok. If updated est code isn't in 7.0p6 you maybe could apply a patch if you won't be upgrading to 7.1, assuming I'm right about recent new code. > > This looks ungood. You maybe should quote the earlier dmesgs re ACPI > > too. This sounds like an issue to take to the acpi@freebsd.org list. > > Hum, about ACPI, if I remember well, there is a BIOS option to > enable/disable ACPI 2 tables. I will take a look at that. There may be some BIOS stuff about SpeedStep options too. Basically you should expect FreeBSD to ignore BIOS settings, except how they influence the ACPI implementation, but some BIOSes can contain surprises. > > Either way, EST isn't functioning, or you'd have a larger range of freqs > > available than these eight, and milliWatt figures instead of those -1. > > There's no sign of 2.66GHz either, if that's expected? > > 2.66 GHz isn't expected, the CPU is an Intel Pentium Dual Core E5200 @ 2.5 > GHz. It's one of the newest 45nm CPUs that were released in August 2008. The > motherboard is an ASUS P5KPL-CM and the BIOS is updated to the latest > version. Cool. I vaguely recall seeing recent est patches for some newer cpus, but not having one myself, I didn't pay much attention. Check the last few months of the freebsd-acpi archives for suitable looking subjects. [..] > > > I found this problem with my machine after I looked at an article > > > telling that the new 45nm Intel CPUs were idling at around 3-4W when > > > Speedstep is decreasing their frequency. And I guess it means that I suspect 3-4W, even per core, would be at a much lower freq than 1GHz, probably nearer the minimum of ~125MHz. > > > I've been running my server at 1.25 GHz all the time since I > > > installed it, which would explain why some compiling jobs were slow! > > > > Sure. Why it starts at 50% I don't know, unless something thinks there > > is a temperature problem? Anyway, you need powerd, and you likely need > > to check the acpi@ list about getting your EST working .. you may even > > need a BIOS upgrade or hacking on your ACPI ASL, but hopefully not .. > > > > And post them more details; at least the full /var/run/dmesg.boot and > > the results of 'sysctl hw.acpi dev.cpu' .. saving rounds of questions. > > About the 50%, if I check the CPU frequency in the BIOS, it is always at > 50%, probably because there is not much possible CPU load in configuring it. No, if it were based on load while looking at the BIOS it'd show you the lowest speed for sure. This sounds like a selection more than a report? > My Core 2 Duo desktop computer has a similar behaviour if I check the > frequency when idle, either under Windows, Linux or in the BIOS. The max CPU > frequency is 2.66 GHz and it always idles at 2 GHz. 2GHz is hardly idling .. maybe there's a BIOS option affecting that too, but it should only affect the starting freq, which powerd should ignore. Under powerd it should drop right back at idle. In fact there've been problems with some machines dropping back to 125, 100, even 75MHz under no or very light load, such that interactive responsiveness is shot and some processes needing fast interrupt response (bursts of wifi traffic, for one) have had issues, prompting some recent new work on algorithms for powerd on SMP systems. See cpufreq(4) about all this, and especially you might want to set debug.cpufreq.lowest to some sensible minimum freq, say 3-500MHz? The acpi@ list is really a better place for this; not too many of the heavy hitters there seem to have much spare time to read questions@ and where I'm mostly just an interested bystander, trying to learn :) cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081209233239.F94168>