Re: Two SpeedStep issues

[Dennis den Brok <d.den.brok%uni-bonn.de@localhost>]

Michael van Elst <mlelstv%serpens.de@localhost> schrieb:
> That's probably correct. The speedstep frequency parameter is
> scaled by the bus clock and it is likely that the driver does
> not identify this correctly. If you build the kernel with
> options EST_DEBUG you will get some information about the
> data found.
>
> However, this shouldn't affect how EST works. Configuring
> 800, 700 or 600 should result in real clock values of 2666,
> 2333 and 2000 respectively.

Hm, it seems something is quite messed up there in
sys/arch/x86/x86. First, on three consequent boots, I got three
different CPU frequencies:

cpu0 at mainbus0 apid 0: Intel 686-class, 2673MHz, id 0x10676
cpu0 at mainbus0 apid 0: Intel 686-class, 3742MHz, id 0x10676
cpu0 at mainbus0 apid 0: Intel 686-class, 3208MHz, id 0x10676

The bus clock is indeed wrong:

est_init_main: bus_clock = 10000

It seems this is because intel_busclock.c does not take the
extmodel into account. My Core2Duo has model #6, which originally
appears to have been some P3, but extmodel #1, which is ignored...
I'm not sure this model# is even correct; wikipedia says it should
be 23!?
Consequently, the rest of the data collected by est_init_main is
interpreted wrongly:

est_init_main: idlo = 0x61a
est_init_main: lo  1116 mV,  600 MHz
est_init_main: raw   26   ,    6    
est_init_main: idhi = 0x820
est_init_main: hi  1212 mV,  800 MHz
est_init_main: raw   32   ,    8    
est_init_main: cur  = 0x820
est_init_main: fake entry 0: 1212 mV,  800 MHz  MSR*100 mV = 3200 freq =  800
est_init_main: fake entry 1: 1180 mV,  700 MHz  MSR*100 mV = 2901 freq =  700
est_init_main: fake entry 2: 1132 mV,  600 MHz  MSR*100 mV = 2602 freq =  600

I didn't check it cancels out when _setting_ speedstep modes, but I 
sure hope it does, considering these voltages! ;-)

On the Celeron side of things...

> Celeron M was used for many different CPUs. What does the
> kernel (or cpuctl identify) say? Enhanced SpeedStep is
> signaled with the EST flag in the features2 register.
>
> If the there is the EST flag but the est driver doesn't
> recognize SpeedStep then it is because the CPU reports
> minimum and maximum clocks to be the same. This is
> Intels way to say: don't play with it but use the
> power saving features of ACPI where we have hidden
> the details.
>
> Unfortunately we don't support he ACPI power saving
> features yet.

... I think OpenBSD just lied. The CPU has original SpeedStep
support but no EST, and I don't think this could actually save
as much power as OpenBSD pretended it was.

> If you want to play yourself with the EST driver,
> sys/arch/x86/x86/est.c is it :)

I now did, and I really did not like it. ;-)

Thanks,

Dennis den Brok