cpuinfo shows wrong MHz value
Joerg Platte
unable to detect the correct speed (1.6 GHz) of the processor:
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Pentium(R) 4 CPU 1.60GHz
stepping : 2
cpu MHz : 13000.000
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pebs bts
bogomips : 3197.21
clflush size : 64
power management:
According to dmesg the kernel detects the CPU correctly during bootup:
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
TSC: PIT calibration matches PMTIMER. 1 loops
Detected 1598.609 MHz processor.
IIRC this behavior started some kernels ago, I can't remember which kernel it
was. Is it possible that the ACPI information is wrong?
regards,
Jörg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Frans Pop
> I'm running kernel 2.6.28.4 and /proc/cpuinfo and powertop and vmware
> are unable to detect the correct speed (1.6 GHz) of the processor:
Isn't this just the result of frequency scaling? Is the processor busy
when you check /proc/cpuinfo?
What are the values in:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
?
Cheers,
FJP
Frans Pop
> I dont think cpu frequency scaling can suddenly make a cpu go from
> 1.6ghz to 13ghz, but if it can, i sure want one!
Ah, sorry. I misread the message and thought the problem was it was
showing 1.3 GHz, which would be a very normal scaling value.
However, it would have helped if the problem had been stated explicitly in
the original message instead of letting others interpret the raw data.
Kasper Sandberg
> Joerg Platte wrote:
> > I'm running kernel 2.6.28.4 and /proc/cpuinfo and powertop and vmware
> > are unable to detect the correct speed (1.6 GHz) of the processor:
>
> Isn't this just the result of frequency scaling? Is the processor busy
> when you check /proc/cpuinfo?
I dont think cpu frequency scaling can suddenly make a cpu go from
1.6ghz to 13ghz, but if it can, i sure want one!
>
Joerg Platte
> On Saturday 14 February 2009, Kasper Sandberg wrote:
> > I dont think cpu frequency scaling can suddenly make a cpu go from
> > 1.6ghz to 13ghz, but if it can, i sure want one!
>
> Ah, sorry. I misread the message and thought the problem was it was
> showing 1.3 GHz, which would be a very normal scaling value.
>
> However, it would have helped if the problem had been stated explicitly in
> the original message instead of letting others interpret the raw data.
Sorry, I should have made it clear that my computer is running with 13 GHz (at
leat according to the kernel). With previous kernels (IIRC 2.6.26) cpuinfo
showed the correct value.
regards,
Jörg
Frans Pop
> Sorry, I should have made it clear that my computer is running with 13
> GHz (at leat according to the kernel). With previous kernels (IIRC
> 2.6.26) cpuinfo showed the correct value.
No problem. The value that is displayed still comes from the cpu frequency
code, so the values I asked for earlier would still be of interest.
Best to have all relevant values. Please do (as root):
# cd /sys/devices/system/cpu/cpu0/cpufreq/
# grep . *
Also, please attach your kernel config.
Joerg Platte
> On Sunday 15 February 2009, Joerg Platte wrote:
> > Sorry, I should have made it clear that my computer is running with 13
> > GHz (at leat according to the kernel). With previous kernels (IIRC
> > 2.6.26) cpuinfo showed the correct value.
>
> No problem. The value that is displayed still comes from the cpu frequency
> code, so the values I asked for earlier would still be of interest.
>
> Best to have all relevant values. Please do (as root):
> # cd /sys/devices/system/cpu/cpu0/cpufreq/
> # grep . *
/sys/devices/system/cpu/cpu0/cpufreq> grep . *
affected_cpus:0
cpuinfo_cur_freq:13000000
cpuinfo_max_freq:13000000
cpuinfo_min_freq:3250000
related_cpus:0
scaling_available_frequencies:3250000 4875000 6500000 8125000 9750000 11375000
13000000
scaling_available_governors:conservative ondemand userspace powersave
performance
scaling_cur_freq:13000000
scaling_driver:p4-clockmod
scaling_governor:performance
scaling_max_freq:13000000
scaling_min_freq:3250000
scaling_setspeed:<unsupported>
>
> Also, please attach your kernel config.
Attached....
Best regards,
Jörg
Joerg Platte
> Am Sonntag, 15. Februar 2009 schrieb Frans Pop:
> > On Sunday 15 February 2009, Joerg Platte wrote:
> > > Sorry, I should have made it clear that my computer is running with 13
> > > GHz (at leat according to the kernel). With previous kernels (IIRC
> affected_cpus:0
> cpuinfo_cur_freq:13000000
> cpuinfo_max_freq:13000000
> cpuinfo_min_freq:3250000
> related_cpus:0
> scaling_available_frequencies:3250000 4875000 6500000 8125000 9750000
> 11375000 13000000
> scaling_available_governors:conservative ondemand userspace powersave
> performance
> scaling_cur_freq:13000000
> scaling_driver:p4-clockmod
> scaling_governor:performance
> scaling_max_freq:13000000
> scaling_min_freq:3250000
> scaling_setspeed:<unsupported>
Looks like p4_clockmod is responsible for these high values. After removing
it /proc/cpuinfo shows the correct values:
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Pentium(R) 4 CPU 1.60GHz
stepping : 2
cpu MHz : 1598.609
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pebs bts
bogomips : 3197.21
clflush size : 64
power management:
best regards,
Jörg
Frans Pop
> Looks like p4_clockmod is responsible for these high values. After
> removing it /proc/cpuinfo shows the correct values:
Can you check whether or not you were also using p4-clockmode with the
last kernel that did show correct values? The same grep command should
show this.
It would also help to know which kernel version was the last working one.
You mentioned 2.6.26, but with some uncertainty. Can you check for 2.6.26
and possibly for 2.6.27?
Note that p4-clockmode does not really help with power saving, but only
with thermal management (prevention of overheating). Possibly the
speedstep or acpi-cpufreq modules will work better for you, but it can
also be they don't support your processor.
That does not mean this issue should not be looked into of course.
Frans Pop
> Looks like p4_clockmod is responsible for these high values. After
> removing it /proc/cpuinfo shows the correct values:
Could you build your kernel with CONFIG_CPU_FREQ_DEBUG enabled and send
the output of dmesg after a boot with p4_clockmod?
Thomas Renninger
>
> On Sunday 15 February 2009, Joerg Platte wrote:
> > Looks like p4_clockmod is responsible for these high values. After
> > removing it /proc/cpuinfo shows the correct values:
>
> Can you check whether or not you were also using p4-clockmode with the
> last kernel that did show correct values? The same grep command should
> show this.
>
> It would also help to know which kernel version was the last working one.
> You mentioned 2.6.26, but with some uncertainty. Can you check for 2.6.26
> and possibly for 2.6.27?
>
> Note that p4-clockmode does not really help with power saving, but only
> with thermal management (prevention of overheating).
Right and if, this should not be done via p4_clockmod, but via ACPI throttling
interface. In fact it could be that latest enhancements in the ACPI throttling
area could interfere with the p4_clockmode driver.
> Possibly the
> speedstep or acpi-cpufreq modules will work better for you, but it can
> also be they don't support your processor.
> That does not mean this issue should not be looked into of course.
IMO it's not worth looking into.
The p4_clockmode driver is broken by design (as ACPI can interfere with it).
I submitted a patch to remove it a while ago. The only reason it did not happen,
where some people who had broken HW (e.g. fan or whatever) the machine did not
shut down due to thermal overheating by using it.
There should be a message when this driver is loaded like:
"This driver is broken. Don't use it, don't complain."
Instead of:
printk(KERN_WARNING PFX "Unknown p4-clockmod-capable CPU. "
"Please send an e-mail to <cpu...@vger.kernel.org>\n");
I will send a patch to the cpufreq list doing that, soon.
Matthew Garrett
> There should be a message when this driver is loaded like:
> "This driver is broken. Don't use it, don't complain."
Please don't. It's perfectly valid (if dumb) for machines to depend on
the CPU for passive cooling even if they don't expose any P or T states.
In that case p4-clockmod is the only code that can manage it. The
removal of the user-visible cpufreq interface should be a strong enough
hint that it's not intended for speed control.
--
Matthew Garrett | mj...@srcf.ucam.org
Matthew Garrett
> On Monday 16 February 2009 17:50:08 Matthew Garrett wrote:
> > On Mon, Feb 16, 2009 at 02:19:50PM +0000, Thomas Renninger wrote:
> >
> > > There should be a message when this driver is loaded like:
> > > "This driver is broken. Don't use it, don't complain."
> >
> > Please don't. It's perfectly valid (if dumb) for machines to depend on
> > the CPU for passive cooling even if they don't expose any P or T states.
> a reason.
We have to deal with insane BIOSes on a regular basis.
> > In that case p4-clockmod is the only code that can manage it. The
> > removal of the user-visible cpufreq interface should be a strong enough
> > hint that it's not intended for speed control.
> AFAIK p4-clockmode is still not synchronized with ACPI throttling?
It ought to work fine with any systems using MSR-based throttling.
> Anyway, I better do not answer on p4_clockmode complaints anymore and
> simply delete them, it's just a waste of time.
Feel free.
Thomas Renninger
>
> > There should be a message when this driver is loaded like:
> > "This driver is broken. Don't use it, don't complain."
>
> Please don't. It's perfectly valid (if dumb) for machines to depend on
> the CPU for passive cooling even if they don't expose any P or T states.
a reason.
> In that case p4-clockmod is the only code that can manage it. The
> removal of the user-visible cpufreq interface should be a strong enough
> hint that it's not intended for speed control.
AFAIK p4-clockmode is still not synchronized with ACPI throttling?
Thus this driver will destroy a valid machine setup where the BIOS exports
throttling states via ACPI.
The driver is broken (and rather useless) and all the complaints about it
get annoying.
I wonder how dangerous it even is. If thermal management on a P4 is
properly implemented via "BIOS throws high temperature MCE and throttles
the CPU itself", could the p4_clockmode driver override the BIOS/HW
settings and still run unthrottled? Danger!
Anyway, I better do not answer on p4_clockmode complaints anymore and
simply delete them, it's just a waste of time.
Thomas
Thomas Renninger
> On Mon, Feb 16, 2009 at 07:13:15PM +0100, Thomas Renninger wrote:
> > On Monday 16 February 2009 17:50:08 Matthew Garrett wrote:
> > > On Mon, Feb 16, 2009 at 02:19:50PM +0000, Thomas Renninger wrote:
> > >
> > > > There should be a message when this driver is loaded like:
> > > > "This driver is broken. Don't use it, don't complain."
> > >
> > > Please don't. It's perfectly valid (if dumb) for machines to
> > > depend on the CPU for passive cooling even if they don't expose any P
> > > or T states.
> > No it's not valid. If the BIOS does not export these, it could be for
> > a reason.
>
> We have to deal with insane BIOSes on a regular basis.
with insane OS implementations...
> > > In that case p4-clockmod is the only code that can manage it. The
> > > removal of the user-visible cpufreq interface should be a strong
> > > enough hint that it's not intended for speed control.
> > AFAIK p4-clockmode is still not synchronized with ACPI throttling?
>
> It ought to work fine with any systems using MSR-based throttling.
This may come from the fact that throttling via ACPI would only kick in
in emergency temperature case. Exactly then, when throttling should be
used, it won't work. I tried it once and I could easily stall the system
by throttling via ACPI and p4_clockmod.
Thomas
Frans Pop
> On Mon, Feb 16, 2009 at 07:13:15PM +0100, Thomas Renninger wrote:
>> AFAIK p4-clockmode is still not synchronized with ACPI throttling?
>
> It ought to work fine with any systems using MSR-based throttling.
So what's your take on this particular bug report then Matthew? Is this a
regression that should be tracked down and fixed, or is this a case where
the user should just not be using the module?
Having a module that loads happily but completely screws up the reported
cpu frequency in /proc/cpuinfo seems suboptimal.
Matthew Garrett
> Matthew Garrett wrote:
> > On Mon, Feb 16, 2009 at 07:13:15PM +0100, Thomas Renninger wrote:
> >> AFAIK p4-clockmode is still not synchronized with ACPI throttling?
> >
> > It ought to work fine with any systems using MSR-based throttling.
>
> So what's your take on this particular bug report then Matthew? Is this a
> regression that should be tracked down and fixed, or is this a case where
> the user should just not be using the module?
It's a bug and it should be fixed. My recollection is that we've hit
this kind of thing before - the frequency calculation code is awkward to
get right on this hardware.
--
Matthew Garrett | mj...@srcf.ucam.org
Joerg Platte
> Can you check whether or not you were also using p4-clockmode with the
> last kernel that did show correct values? The same grep command should
> show this.
The last kernel that was working correct was 2.6.24 (here the output from
2.6.24.6):
affected_cpus:0
cpuinfo_cur_freq:1600000
cpuinfo_max_freq:1600000
cpuinfo_min_freq:400000
scaling_available_frequencies:400000 600000 800000 1000000 1200000 1400000
1600000
scaling_available_governors:conservative ondemand userspace powersave
performance
scaling_cur_freq:1600000
scaling_driver:p4-clockmod
scaling_governor:performance
scaling_max_freq:1600000
scaling_min_freq:400000
root@jako:/sys/devices/system/cpu/cpu0/cpufreq> uname -a
Linux jako 2.6.24.6 #1 PREEMPT Tue Feb 17 20:33:58 CET 2009 i686 GNU/Linux
The log output is somewhat limited, because I forgot to enable debugging:
root@jako:/sys> dmesg | grep clock
Time: tsc clocksource has been installed.
intel8x0_measure_ac97_clock: measured 55906 usecs
intel8x0: measured clock 71 rejected
intel8x0: clocking to 48000
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
Here is the output from 2.6.28.5 and debug info enabled:
root@jako:~> dmesg | grep clock
intel8x0_measure_ac97_clock: measured 55894 usecs
intel8x0: measured clock 71 rejected
intel8x0: clocking to 48000
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
It looks like the debug code does not provide more information.
> It would also help to know which kernel version was the last working one.
> You mentioned 2.6.26, but with some uncertainty. Can you check for 2.6.26
> and possibly for 2.6.27?
I was wrong, it was working long ago with kernel 2.6.24, sorry.
> Note that p4-clockmode does not really help with power saving, but only
> with thermal management (prevention of overheating). Possibly the
> speedstep or acpi-cpufreq modules will work better for you, but it can
> also be they don't support your processor.
Yes, I know. I just installed it to play with it and now I'm using the
performance governor all the time which disables frequency modulation.
> That does not mean this issue should not be looked into of course.
I can simply unload the module but a fix would be appreciated as well :)
regards,
Jörg
Frans Pop
> The last kernel that was working correct was 2.6.24 (here the output
> from 2.6.24.6):
Right. I suspect then that the following commit may be the cause of the
regression:
commit ed9cbcd40004904dbe61ccc16d6106a7de38c998
Author: Zhao Yakui <yakui...@intel.com>
Date: Tue Nov 20 14:20:21 2007 -0500
Revert "speedstep-lib.c: fix frequency multiplier for Pentium4 models 0&1"
That would exactly explain the factor 8 of the error.
Do you have a line like the following in your debug output?
P4 - FSB %u kHz; Multiplier %u; Speed %u kHz\n
If so, what does it say for .24 and .28?
Can you please provide the output of 'x86info -a' (as root) after loading
the cpuid module?
Joerg Platte
> commit ed9cbcd40004904dbe61ccc16d6106a7de38c998
> Author: Zhao Yakui <yakui...@intel.com>
> Date: Tue Nov 20 14:20:21 2007 -0500
> Revert "speedstep-lib.c: fix frequency multiplier for Pentium4 models
> 0&1"
>
> That would exactly explain the factor 8 of the error.
Yes, looks like thats the reason.
> Do you have a line like the following in your debug output?
> P4 - FSB %u kHz; Multiplier %u; Speed %u kHz\n
> If so, what does it say for .24 and .28?
There is no such message in the log.
> Can you please provide the output of 'x86info -a' (as root) after loading
> the cpuid module?
Here it is:
x86info v1.21. Dave Jones 2001-2007
Feedback to <da...@redhat.com>.
Found 1 CPU
--------------------------------------------------------------------------
eax in: 0x00000000, eax = 00000002 ebx = 756e6547 ecx = 6c65746e edx =
49656e69
eax in: 0x00000001, eax = 00000f12 ebx = 00010808 ecx = 00000000 edx =
3febfbff
eax in: 0x00000002, eax = 665b5001 ebx = 00000000 ecx = 00000000 edx =
007a7040
eax in: 0x80000000, eax = 80000004 ebx = 00000000 ecx = 00000000 edx =
00000000
eax in: 0x80000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx =
00000000
eax in: 0x80000002, eax = 20202020 ebx = 20202020 ecx = 20202020 edx =
6e492020
eax in: 0x80000003, eax = 286c6574 ebx = 50202952 ecx = 69746e65 edx =
52286d75
eax in: 0x80000004, eax = 20342029 ebx = 20555043 ecx = 30362e31 edx =
007a4847
Family: 15 Model: 1 Stepping: 2 Type: 0 Brand: 8
CPU Model: Pentium 4 (Willamette) [D0] Original OEM
Processor name string: Intel(R) Pentium(R) 4 CPU 1.60GHz
Feature flags:
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflsh ds acpi mmx fxsr sse sse2 ss ht tm
Extended feature flags:
Pentium 4 specific MSRs:
IA32_PLATFORM_ID=0008000000000000
System bus in order queue depth=12
MSR_EBC_FREQUENCY_ID=000000008201ff00
IA32_BIOS_SIGN_ID=0000002e00000000
Processor serial number is enabled
Fast string enable is set
x87 FPU Fopcode compatability mode is unset
Thermal monitor enable is set
Split lock disable is unset
L3 cache disable is set
Performance monitoring is available
Suppress lock enable is unset
Prefetch queue disable is unset
FERR# Interrupt reporting enable is unset
Branch trace storage unavailable is unset
Precise Event Based Sampling Unavailable is unset
Cache info
Instruction trace cache: 12K uOps, 8-way associative.
L1 Data cache: 8KB, sectored, 4-way associative. 64 byte line size.
L2 unified cache: 256KB, sectored, 8-way associative. 64 byte line size.
TLB info
Instruction TLB: 4K, 2MB or 4MB pages, fully associative, 64 entries.
Data TLB: 4KB or 4MB pages, fully associative, 64 entries.
Number of reporting banks : 4
Number of extended MC registers : 12
Bank: 0 (0x400)
MC0CTL: 00000000 00000000 00000000 00000000
00000000 00000000 11111111 11111111
MC0STATUS: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
MC0ADDR: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
Bank: 1 (0x404)
MC1CTL: 00000000 00000000 00000000 00000000
00000000 00000011 10000000 00000000
MC1STATUS: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
MC1ADDR: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
Bank: 2 (0x408)
MC2CTL: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 10000000
MC2STATUS: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
MC2ADDR: Couldn't read MSR 0x40a
Bank: 3 (0x40c)
MC3CTL: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 01111110
MC3STATUS: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
MC3ADDR: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
The physical package supports 1 logical processors
Microcode version: 0x000000000000002e
Connector type: Socket423 (PGA423 Socket)
Datasheet: http://developer.intel.com/design/pentium4/datashts/24919805.pdf
Errata: http://developer.intel.com/design/pentium4/specupdt/249199.htm
MTRR registers:
MTRRcap (0xfe): 0x0000000000000508
MTRRphysBase0 (0x200): 0x0000000000000006
MTRRphysMask0 (0x201): 0x0000000fc0000800
MTRRphysBase1 (0x202): 0x0000000000000000
MTRRphysMask1 (0x203): 0x0000000000000000
MTRRphysBase2 (0x204): 0x0000000000000000
MTRRphysMask2 (0x205): 0x0000000000000000
MTRRphysBase3 (0x206): 0x0000000000000000
MTRRphysMask3 (0x207): 0x0000000000000000
MTRRphysBase4 (0x208): 0x0000000000000000
MTRRphysMask4 (0x209): 0x0000000000000000
MTRRphysBase5 (0x20a): 0x0000000000000000
MTRRphysMask5 (0x20b): 0x0000000000000000
MTRRphysBase6 (0x20c): 0x0000000000000000
MTRRphysMask6 (0x20d): 0x0000000000000000
MTRRphysBase7 (0x20e): 0x0000000000000000
MTRRphysMask7 (0x20f): 0x0000000000000000
MTRRfix64K_00000 (0x250): 0x0606060606060606
MTRRfix16K_80000 (0x258): 0x0606060606060606
MTRRfix16K_A0000 (0x259): 0x0000000000000000
MTRRfix4K_C8000 (0x269): 0x0000000000000000
MTRRfix4K_D0000 0x26a: 0x0000000000000000
MTRRfix4K_D8000 0x26b: 0x0000000000000000
MTRRfix4K_E0000 0x26c: 0x0505050505050505
MTRRfix4K_E8000 0x26d: 0x0505050505050505
MTRRfix4K_F0000 0x26e: 0x0505050505050505
MTRRfix4K_F8000 0x26f: 0x0505050505050505
MTRRdefType (0x2ff): 0x0000000000000c00
1.60GHz processor (estimate).
best regards and thank you for your help
Jörg
Frans Pop
> Am Mittwoch, 18. Februar 2009 schrieb Frans Pop:
> > commit ed9cbcd40004904dbe61ccc16d6106a7de38c998
> > Author: Zhao Yakui <yakui...@intel.com>
> > Date: Tue Nov 20 14:20:21 2007 -0500
> > Revert "speedstep-lib.c: fix frequency multiplier for Pentium4
> > models 0&1"
> >
> > That would exactly explain the factor 8 of the error.
>
> Yes, looks like thats the reason.
It looks as if http://bugzilla.kernel.org/10968 has a fix for this issue,
but that that patch never got included in the kernel.
For start of current thread, see:
http://www.gossamer-threads.com/lists/linux/kernel/1034291?page=last
Joerg Platte
> It looks as if http://bugzilla.kernel.org/10968 has a fix for this issue,
> but that that patch never got included in the kernel.
Yes, this patch fixes the issue and the patch still applies to kernel
2.6.28.6. Please push it into mainline.
regards and many thanks for providing this patch,
Jörg