Bug 439266 - cat /proc/cpuinfo cpu Mhz is incorrect
cat /proc/cpuinfo cpu Mhz is incorrect
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
x86_64 Linux
medium Severity low
: rc
: ---
Assigned To: john cooper
Virtualization Bugs
Depends On:
  Show dependency treegraph
Reported: 2008-03-27 15:13 EDT by Jeffrey Needham
Modified: 2014-07-24 23:45 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-23 15:40:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg output (28.26 KB, text/plain)
2008-03-27 15:13 EDT, Jeffrey Needham
no flags Details
output from xm dmesg (8.20 KB, text/plain)
2008-03-27 15:14 EDT, Jeffrey Needham
no flags Details

  None (edit)
Description Jeffrey Needham 2008-03-27 15:13:42 EDT
Description of problem:
system is incorrectly identifying the speed of the processors

Version-Release number of selected component (if applicable):
RHEL5.1 Beta (March 03 build)

How reproducible:
Only occurs on a 4 socket AMD quad-core Tyan TX46 (4985) with 8350 (family 16) CPUs

Steps to Reproduce:
1. boot with xen kernel
2. cat /proc/cpuinfo
Actual results:
CPU frequency is being reported as 3300Mhz. 

Expected results:
It should be 2400Mhz

Additional info:
same result with 5.1
clocksource=pit on the hv command line
Comment 1 Jeffrey Needham 2008-03-27 15:13:42 EDT
Created attachment 299380 [details]
dmesg output
Comment 2 Jeffrey Needham 2008-03-27 15:14:24 EDT
Created attachment 299381 [details]
output from xm dmesg
Comment 3 Michal Nowak 2008-03-27 16:03:03 EDT
Isn't it this the problem?

powernow-k8: Your BIOS does not provide _PSS objects.  PowerNow! does not work
on SMP systems without _PSS objects.  Complain to your BIOS vendor.

see https://bugzilla.redhat.com/show_bug.cgi?id=435321#c3

Might be solved by BIOS upgrade.

Is it seen on bare metal?
Comment 4 Chris Lalancette 2008-03-27 16:10:48 EDT
No, that shouldn't be the problem.  That's basically a message from the powernow
driver saying it can't load because it can't figure out the power topology of
the system.  So powernow is just refusing to initialize.

Now, the problem certainly *could* be a BIOS problem, but I don't have any data
to back that up either way.

Chris Lalancette
Comment 5 Jeffrey Needham 2008-03-27 18:53:58 EDT
When the bare metal kernel is running, cpuinfo reports the correct frequency. It
could still be a BIOS issue if the HV derives the clock in a way that is
different from the bare metal kernel.  I often see this message when powernow is
disabled in the BIOS. I currently do have powernow disabled in the BIOS.  

The BIOS is the BIOS from Tyan as it was required to support quad-core.

Comment 6 Michal Nowak 2008-04-02 07:34:40 EDT
Do anyone know whether is it somehow related to bug 435321? Or at least to
cpuspeed? My impression is that those two issues are not related.
Comment 7 Bill Burns 2008-04-02 08:16:51 EDT
More like bug 428710. On that one we saw the Hypervisor correctly determine the
cpu speed itself but due to a bad calibration, cause dom0 to get it wrong and
thus the 'time went backwards' messages resulted. It would be interesting to
know the same workaround has an effect. Adding a dom0_mem=512M boot arg to the
Xen hypervisor. What this does is delay the start time of dom0, and gives the
hypervisor a chance to recalibrate the clock and that usually makes dom0 happy.
Can you try that test?
Comment 8 Jeffrey Needham 2008-04-02 14:05:11 EDT
rebooted with the following:
        kernel /xen.gz-2.6.18-84.el5 dom0_mem=512M
        module /vmlinuz-2.6.18-84.el5xen ro root=LABEL=/1

And this produced the correct clock frequency. this does only leave you with
512M of RAM, so I guess I need the fix for this BZ first.

Comment 9 Bill Burns 2008-04-02 14:35:56 EDT
Thanks. It only limits dom0 to 512M, the rest of the memory is available for
guests, which is normally what is desired. But this was not intended to suggest
you need to run this way. It was to see if the problem was similar to bug 428710
and indeed it seems to be.
Comment 10 john cooper 2008-04-02 16:52:05 EDT
Jeffrey, where might this system be located?  Could you also
provide the cpu core revisions and the BIOS version in use?
Have you found this problem only on the above single machine or
have you been able to reproduce it elsewhere on another 4 socket
AMD quad-core Tyan TX46 MB?
Comment 11 Jeffrey Needham 2008-04-02 18:50:15 EDT
I am trying to secure another system and also figure out how to get them so that
there is vpn access.  Currently they live in my garage.

Comment 12 john cooper 2008-04-10 08:20:39 EDT
(In reply to comment #11)
> I am trying to secure another system and also figure out how to get them so that
> there is vpn access.  Currently they live in my garage.

Jeffrey, any update on this case or additional information you can
provide relative to my query (comment #10) above?

Comment 13 Jeffrey Needham 2008-04-23 15:28:58 EDT
I updated the BIOS on the TX46 (a 4985 board) to 2.03 and the clock now reports
correctly. This can be closed.
Comment 14 Bill Burns 2008-04-23 15:40:39 EDT
Closing as per comment #13.
Comment 15 john cooper 2008-04-23 19:03:42 EDT
[including some e-mail context here for possible future

That's a little bizarre.  Reason being is the CPU frequency
calculation is being done via two methods.  One by Xen
for the sole purpose of printing the CPU freq during Xen
boot and the second method to publish such to the guest
OSes -- the initial value of which is in error and is being
displayed during guest boot.  My concern is we may still
have an oddity in the latter calculation potentially being
masked now by the new BIOS.

That said I don't see how a BIOS would affect what we're
finding as if the CPU clocks are stable early on I don't
know what might cause them to be unstable after the initial
Xen calculation is correctly completing.  I suppose the
BIOS could be getting control and mucking with the master
clock but that seems unlikely short of some type of
frequency scaling operation.

Note You need to log in before you can comment on or make changes to this bug.