Some more update:
So to see, the my system is
not running on 533 MHz. This is the output of /proc/cpuinfo:
Code: Select all
jlinkels@jlinkels_lt:~# cat /proc/cpuinfo
[...]
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.86GHz
stepping : 8
cpu MHz : 532.048
cache size : 2048 KB
[...]
bogomips : 1050.91
Yes, that looks like 533 MHz. However when I run "mhz" from the lmbench benchmark suite, it indicated that the CPU was running on 798 Mhz. Now that could have been the quantum effect (as soon as you try to observe a particle, it state is altered) since the governor might have tried to increase the CPU frequency. This actually happened when I run "mhz" a few times in a quick fashion. The CPU frequency was pushed upwards. And came down again.
However, without running "mhz", and with the output of /proc/cpuinfo as above, I cat-ed /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq which showed:
Code: Select all
root@jlinkels_lt:/sys/devices/system/cpu/cpu0/cpufreq# cat cpuinfo_cur_freq
798000
and to my surprise when I asked for /proc/cpuinfo again, it showed:
Code: Select all
root@jlinkels_lt:/sys/devices/system/cpu/cpu0/cpufreq# cat /proc/cpuinfo
[...]
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.86GHz
stepping : 8
cpu MHz : 798.073
cache size : 2048 KB
[...]
bogomips : 1576.37
After this the CPU frequency would not go down anymore. This is logical, as speedstep-centrino asks for the current value of the IA32_PERF_CTL register and finds 0x0403. This is the same value as the speedstep-centrino wants to write there, so it draws the conclusion that nothing has to be written.
Surprisingly, when I do
not cat cpufreq_cur_frequency in between, the governor nicely scales the frequency up and down until /proc/cpuinfo shows 533 Mhz again.
This behavior (showing a low frequency value in the beginning, and then locking at a certain minimum) is in line with other reports in this thread. My conclusion so far is:
- The CPU never actually scales down to 533 MHz. (or 400 MHz on a 400 MHz system), being 1x bus frequency
- For some time /proc/cpuinfo is not synchronized with cpuinfo_cur_frequency
- There seems to be a mechanism which has to sync what the kernel thinks the CPU frequency is and the actual frequency. By trying to put an impossible value in the CPU control register, these value get out of sync.
Too bad...
Now since speedstep-centrino
does write the value for voltage = 748 mV into the CPU, I am wondering whether this voltage is actually used, or that the entire write to IA32_PERF_CTL is ignored. Which would be very bad, because that means that still to high a value for the core voltage is used. I have my doubts whether that voltage is used. First, acpi -V shows the same temperature values as before (when I used the ACPI tables) and the fan keeps running and secondly, even with 748 mV at 800 MHz the computer remained as stable as a rock.
The only thing which I will still do is removing the 533 MHz from the speedstep-centrino table and see whether this some influence on the temperature on 800 MHz. 800 MHz is a valid P-setting, and I expect the requested core voltage to be used.
If anyone else has other experiences, or has obtained new results, please post here.
jlinkels
)
