Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 07 Jun 2008 23:05:44 +0300
From:      Evren Yurtesen <yurtesen@ispro.net>
To:        Jeremy Chadwick <koitsu@FreeBSD.org>
Cc:        freebsd-stable@freebsd.org, Andrew Snow <andrew@modulus.org>, John Baldwin <jhb@freebsd.org>
Subject:   Re: cpufreq broken on core2duo
Message-ID:  <484AEA18.4030901@ispro.net>
In-Reply-To: <20080607164812.GA11072@eos.sc1.parodius.com>
References:  <4847072E.5000709@ispro.net> <484713B2.5030200@ispro.net> <48471834.30905@modulus.org> <200806051040.28319.jhb@freebsd.org> <484AA07A.2010308@ispro.net> <20080607164812.GA11072@eos.sc1.parodius.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Jeremy Chadwick wrote:
> On Sat, Jun 07, 2008 at 05:51:38PM +0300, Evren Yurtesen wrote:
>> By the way, there is another thing I am wondering about. If I enable HTT 
>> and Intel Enhanced SpeedStep in bios on a 3.00GHZ p4 CPU I see:
>>
>> cpu0: <ACPI CPU> on acpi0
>> acpi_perf0: <ACPI CPU Frequency Control> on cpu0
>> p4tcc0: <CPU Frequency Thermal Control> on cpu0
>> cpu1: <ACPI CPU> on acpi0
>> est1: <Enhanced SpeedStep Frequency Control> on cpu1
>> est: CPU supports Enhanced Speedstep, but is not recognized.
>> est: cpu_vendor GenuineIntel, msr f2700000f27
>> device_attach: est1 attach returned 6
>> p4tcc1: <CPU Frequency Thermal Control> on cpu1
>>
>> dev.cpu.0.freq_levels: 1500/27000 1312/23625 1200/13000 1050/11375 900/9750 
>> 750/8125 600/6500 450/4875 300/3250 150/1625
>> dev.acpi_perf.0.freq_settings: 1500/27000 1200/13000
>> dev.cpufreq.0.%driver: cpufreq
>> dev.cpufreq.0.%parent: cpu0
>> dev.cpufreq.1.%driver: cpufreq
>> dev.cpufreq.1.%parent: cpu1
>> dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
>> 2500/-1 1250/-1
>> dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
>> 2500/-1 1250/-1
>>
>> and it does not allow me to set the freq. of the cpu.
> 
> How are you setting the frequency?  Are you using powerd?  You do not
> have to enable SpeedStep in your BIOS to achieve throttling CPU clock
> speed.  In fact, I would highly recommend leaving EIST/SpeedStep in the
> BIOS *disabled*, and let powerd adjust the clock frequency via ACPI.

I have tested if it is working or not without using powerd. However you are 
right, SpeedStep in bios seem to be adding some ACPI support which looks like 
kind of broken.

In either case, I get error when I have HTT as powerd (powerd -v) is only able 
to change 1 CPUs speed (obviously). Perhaps this can be fixed in future hopefully.

In the bios, there is also Enhanced C1 support which seems to be reducing the 
vcore voltage at the same clock speed. (is this normal even?)

>> I see the vcore goes to 2.32 when I set the speed to 150 according to 
>> mbmon, and when I set the speed to 1500 vcore goes to 2.51
> 
> mbmon is giving you wrong values.  There is no way your Vcore on a P4 is
> 2.32 or 2.51 volts.  It's very likely that mbmon doesn't support your
> hardware monitoring I/C.  What motherboard (exact model) do you have?

I thought about that actually but at this moment the importance is that it is 
changing only under certain conditions, there is probably some mistake in mbmon 
which skews the results.

This is the motherboard (information from the datacenter):
http://www.supermicro.com/products/motherboard/PD/E7230/PDSML-LN2.cfm
Although kenv | grep smbios show PDSBM can this be or the datacenter is wrong?

I just went to bios and says 1.264v so I guess it is safe to assume that mbmon 
was showing double.

>> Independent of HTT being active or not, when I enable Intel Enhanced 
>> SpeedStep from the bios I start seeing calcru messages:
>>
>> calcru: runtime went backwards from 6 usec to 3 usec for pid 37 (pagezero)
>> calcru: runtime went backwards from 6 usec to 3 usec for pid 36 (vmdaemon)
>> calcru: runtime went backwards from 170 usec to 138 usec for pid 35 (pagedaemon)
>> calcru: runtime went backwards from 553 usec to 291 usec for pid 15 (swi6: 
>> task queue)
>> calcru: runtime went backwards from 15521 usec to 10366 usec for pid 2 (g_event)
>> calcru: runtime went backwards from 25 usec to 12 usec for pid 11 (swi1: net)
>> calcru: runtime went backwards from 4417 usec to 3960 usec for pid 1 (init)
>> calcru: runtime went backwards from 2084385 usec to 1793542 usec for pid 1 (init)
>> calcru: runtime went backwards from 408 usec to 204 usec for pid 0 (swapper)
> 
> I've documented this problem quite clearly on my Commonly Reported
> Issues wiki page.  See "Kernel - EIST incompatibilities":
> 
> http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues
> 
> The solution is to keep EIST (SpeedStep) disabled in the BIOS.  You can
> still use powerd to adjust CPU clock frequency via ACPI.

Yes, I have nothing against keeping it closed. :)

>> Another weird thing is that if I keep HTT enable but disable Intel Enhanced 
>> SpeedStep then I see:
>>
>> ...
>>
>> Also the sysctl changes do not return an error however the vcore voltage 
>> still remains constant according to mbmon.
> 
> Again: it's highly unlikely mbmon is returning correct values.  mbmon
> and healthd both were written with very old hardware (circa late 90s,
> very early 2001-2002) in mind.  The chips they support are not very
> common on consumer motherboards, and are no longer used on server
> motherboards.
> 
> You might be interested in my bsdhwmon(8) application, but please note
> I'm trying to avoid supporting any sort of "consumer" motherboards,
> because many of them do not offer SMBus tie-ins, not to mention many
> consumer board vendors don't provide any sort of documentation on how to
> access said H/W IC functionality:

Yes, as a coincidence I found:
http://fixunix.com/freebsd/384760-looking-supermicro-hardware-owners.html

I have 2 other servers with:
http://www.supermicro.com/products/motherboard/Xeon1333/5000V/X7DVL-i.cfm
(eh this one gives "X7DVL" correctly in kenv output also :) )
and I have some Intel products. I can test out bsdhwmon...

I will send you the bios screenshots later to your e-mail. I have to leave now 
for a short while.

Thanks,
Evren



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?484AEA18.4030901>