Red Hat Bugzilla – Bug 439266
cat /proc/cpuinfo cpu Mhz is incorrect
Last modified: 2014-07-24 23:45:43 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 3. 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
Created attachment 299380 [details] dmesg output
Created attachment 299381 [details] output from xm dmesg
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?
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
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.
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.
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?
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.
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.
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?
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.
(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?
I updated the BIOS on the TX46 (a 4985 board) to 2.03 and the clock now reports correctly. This can be closed.
Closing as per comment #13.
[including some e-mail context here for possible future reference] 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.