Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 07 Jun 2008 17:51:38 +0300
From:      Evren Yurtesen <yurtesen@ispro.net>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-stable@freebsd.org, Andrew Snow <andrew@modulus.org>
Subject:   Re: cpufreq broken on core2duo
Message-ID:  <484AA07A.2010308@ispro.net>
In-Reply-To: <200806051040.28319.jhb@freebsd.org>
References:  <4847072E.5000709@ispro.net> <484713B2.5030200@ispro.net> <48471834.30905@modulus.org> <200806051040.28319.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On Wednesday 04 June 2008 06:33:24 pm Andrew Snow wrote:
>> Evren Yurtesen wrote:
>>
>>> When you say that it doesnt work, does it give an error or? In my case 
>>> it doesnt give any errors just says it set it but I see that nothing is 
>>> set.
>> Here's one box:
>>
>> CPU: Intel(R) Core(TM)2 Duo CPU  E8500  @ 3.16GHz
>> cpu0: <ACPI CPU> on acpi0
>> est0: <Enhanced SpeedStep Frequency Control> on cpu0
>> est: CPU supports Enhanced Speedstep, but is not recognized.
>> est: cpu_vendor GenuineIntel, msr 61a49200600091a
>> device_attach: est0 attach returned 6
>> p4tcc0: <CPU Frequency Thermal Control> on cpu0
>>
>>
>> Here's another one:
>> CPU: Intel(R) Xeon(R) CPU  E5410  @ 2.33GHz
>> cpu0: <ACPI CPU> on acpi0
>> est0: <Enhanced SpeedStep Frequency Control> on cpu0
>> est: CPU supports Enhanced Speedstep, but is not recognized.
>> est: cpu_vendor GenuineIntel, msr 720072006000720
>> device_attach: est0 attach returned 6
>> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> 
> You can try http://www.FreeBSD.org/~jhb/patches/est_msr.patch.  It won't give 
> you the full range of speeds for you CPU, but it should give you the high and 
> low values that we can guess from the upper 32-bits of the MSR.
> 

The patch is causing errors in kernel compilation in FreeBSD 7-Stable.

inter-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions 
-nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -mcmodel=kernel -mno-red-zone  -mfpmath=387 -mno-sse 
-mno-sse2 -mno-mmx -mno-3dnow  -msoft-float -fno-asynchronous-unwind-tables 
-ffreestanding -Werror  /usr/src/sys/kern/imgact_elf32.c
cc -c -O -pipe -march=nocona -std=c99  -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000  -mcmodel=kernel -mno-red-zone  -mfpmath=387 
-mno-sse -mno-sse2 -mno-mmx -mno-3dnow  -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -Werror 
/usr/src/sys/i386/cpufreq/powernow.c
cc -c -O -pipe -march=nocona -std=c99  -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000  -mcmodel=kernel -mno-red-zone  -mfpmath=387 
-mno-sse -mno-sse2 -mno-mmx -mno-3dnow  -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -Werror 
/usr/src/sys/i386/cpufreq/est.c
/usr/src/sys/i386/cpufreq/est.c: In function 'bus_speed_ok':
/usr/src/sys/i386/cpufreq/est.c:1206: error: invalid storage class for function 
'est_msr_info'
cc1: warnings being treated as errors
/usr/src/sys/i386/cpufreq/est.c:1206: warning: no previous prototype for 
'est_msr_info'
/usr/src/sys/i386/cpufreq/est.c:1270: error: invalid storage class for function 
'est_get_id16'
/usr/src/sys/i386/cpufreq/est.c:1270: warning: no previous prototype for 
'est_get_id16'
/usr/src/sys/i386/cpufreq/est.c:1276: error: invalid storage class for function 
'est_set_id16'
/usr/src/sys/i386/cpufreq/est.c:1276: warning: no previous prototype for 
'est_set_id16'
/usr/src/sys/i386/cpufreq/est.c:1303: error: invalid storage class for function 
'est_get_current'
/usr/src/sys/i386/cpufreq/est.c:1303: warning: no previous prototype for 
'est_get_current'
/usr/src/sys/i386/cpufreq/est.c:1326: error: invalid storage class for function 
'est_settings'
/usr/src/sys/i386/cpufreq/est.c:1326: warning: no previous prototype for 
'est_settings'
/usr/src/sys/i386/cpufreq/est.c:1350: error: invalid storage class for function 
'est_set'
/usr/src/sys/i386/cpufreq/est.c:1350: warning: no previous prototype for 'est_set'
/usr/src/sys/i386/cpufreq/est.c:1371: error: invalid storage class for function 
'est_get'
/usr/src/sys/i386/cpufreq/est.c:1371: warning: no previous prototype for 'est_get'
/usr/src/sys/i386/cpufreq/est.c:1390: error: invalid storage class for function 
'est_type'
/usr/src/sys/i386/cpufreq/est.c:1390: warning: no previous prototype for 'est_type'
/usr/src/sys/i386/cpufreq/est.c:1397: error: expected declaration or statement 
at end of input
*** Error code 1

Stop in /usr/obj/usr/src/sys/MAIL.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
mail:/usr/src#


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.

If I disable HTT then I see:

cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est0: Setting 1500 MHz
p4tcc0: <CPU Frequency Thermal Control> on cpu0

dev.cpu.0.freq: 1500
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.est.0.freq_settings: 1500/27000 1200/13000
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
2500/-1 1250/-1

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


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)



Another weird thing is that if I keep HTT enable but disable Intel Enhanced 
SpeedStep then I see:

cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr f2700000f27
device_attach: est0 attach returned 6
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

and

dev.cpu.0.freq: 2978
dev.cpu.0.freq_levels: 2978/-1 2605/-1 2233/-1 1861/-1 1489/-1 1116/-1 744/-1 372/-1
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
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
dev.cpufreq.1.%driver: cpufreq
dev.cpufreq.1.%parent: cpu1

Notice the correct frequency and changing dev.cpu.0.freq effects the openssl 
speed rsa test so it is working. However when I change the dev.cpu.0.freq I 
receive an error (but it changes anyway):

mail:/root#sysctl -w dev.cpu.0.freq=2978
dev.cpu.0.freq: 744
sysctl: dev.cpu.0.freq: Invalid argument
mail:/root#sysctl -w dev.cpu.0.freq=2978
dev.cpu.0.freq: 2978
sysctl: dev.cpu.0.freq: Invalid argument
mail:/root#

and the openssl speed rsa test returns results which are consistent with the 
speed set. But, regardless of the speed set, mbmon shows 2.54volts all the time.


When HTT and Intel Enhanced Speedstep is disabled in bios I see:

cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr f2700000f27
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0

and

dev.cpu.0.freq: 2977
dev.cpu.0.freq_levels: 2977/-1 2604/-1 2232/-1 1860/-1 1488/-1 1116/-1 744/-1 372/-1
dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 
2500/-1 1250/-1
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0

Also the sysctl changes do not return an error however the vcore voltage still 
remains constant according to mbmon.

Is there a reason why HTT is not properly detected by cpufreq and behaved 
accordingly?

Thanks,
Evren




Thanks,
Evren



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