Red Hat Bugzilla – Bug 626893
Maximum available frequency on Xeon X3210 (2.13GHz) is 1600MHz when using p4-clockmod
Last modified: 2013-01-10 02:29:00 EST
Description of problem:
After clean installation of RHEL6 on redclient-01.rhts.bos.redhat.com p4-clockmod kernel module is loaded. Maximum available frequency is only 1600Mhz but CPU supports 2130MHz. After unloading p4-clockmod is frequency correctly set to 2130MHz.
In dmesg appears this note
p4-clockmod: Warning: EST-capable CPU detected. The acpi-cpufreq module offers voltage scaling in addition of frequency scaling. You should use that instead of p4-clockmod, if possible.
We tried to unload p4-clockmod and load acpi-cpufreq but received error:
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.32-66.el6.x86_64/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device
Version-Release number of selected component (if applicable):
Linux redclient-01.rhts.bos.redhat.com 2.6.32-66.el6.x86_64 #1 SMP Wed Aug 18 00:24:41 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Steps to Reproduce:
1. make sure that p4-clockmod is loaded
2. cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
3. rmmod p4-clockmod
4. cat /proc/cpuinfo
cpuinfo_max_freq is only 1600Mhz on 2130MHz CPU
Correct value of maximum CPU frequency in /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
This problem is in redeye.rhts.bos.redhat.com
One thing Im fairly certain of is that redeye has cpuspeed scaling disabled at the BIOS. I will investigate.
p4-clockmod assumes that the CPU is running at maximum frequency when it's loaded. HP's firmware changes the speed of the system behind the operating system's back, and so if p4-clockmod is loaded when the speed has been reduced by the firmware p4-clockmod assumes that the CPU's "low" speed is in fact high speed. p4-clockmod is blisfully unaware of the firmware's CPU speed changes and so will report an incorrect speed.
This is purely an issue in terms of the reporting of the frequency. The firmware will be scaling the CPU's frequency behind our back, so under load the CPU will be running at full speed regardless of the value reported in cpuinfo.
There are three fixes to this:
1) Disable power management entirely in the BIOS
2) Ensure that power management is set to "OS Control" in the BIOS. The firmware will then leave the CPU frequency alone and we will have control through ACPI. This means that we can report the speed correctly. If cpuspeed is disabled the system will then always run at full speed.
3) On more recent HPs, the Processor Clocking Control interface managed by pcc-cpufreq allows us to identify the actual CPU frequency
I don't have access to the none of the affected systems but I believe that we saw following:
1) p4-clockmod is loaded after reboot. Max reported freq. is 1.6GHz.
2) rmmod p4-clockmod => Freq. as reported by /proc/cpuinfo is 2.13GHz
3) modprobe p4-clockmod => Reported max. available freq. is 1.6Ghz
Barry, could you please confirm this?
Matt, would it be expected behavior?
I think we should run linpack benchmark to chekc what the real cpufreq is.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Some HP Proliant servers may report incorrect CPU frequency values in /proc/cpuinfo or /sys/device/system/cpu/*/cpufreq. This is due to the firmware manipulating the CPU frequency without providing any notification to the operating system. To avoid this ensure that the "HP Power Regulator" option in the BIOS is set to "OS Control". An alternative available on more recent systems is to set "Collaborative Power Control" to "Enabled".
I've benchmarked and confirmed that the system is running at full frequency even when /proc/cpuinfo claims that the frequency is 1.6GHz. This is completely expected behaviour when the BIOS is configured to "HP Dynamic Power Savings Mode" and "Collaborative Power Control" is either disabled or not available on the system.
To prevent the firmware from interfering, either set the BIOS to "HP Static High Performance Mode" or "OS Control". If "Collaborative Power Control" is available and enabled we will report the correct frequency even if "HP Dynamic Power Savings Mode" is enabled.
I will be checking the BIOS of redeye tomorrow to see how everything is set. I have access to the iLOs if the console access gets flaky
I Can confirm that CPU probably runs at full speed even if /proc/cpuinfo shows only 1600MHz. There is no performance improvement after unloading p4-clockmod in my tests. I've tried to access BIOS of redclient04 via console but only think i can see is this diagnostic menu
Diagnostic Utility, Version 2.15
Copyright 1982, 2007 Hewlett-Packard Development Company, L.P.
|Memory Test |
|CPU Test |
|Boot Disk Test|
I cannot exit it, and now this system boots directly to this menu even after power down/up . Barry can you grab redclient04 and set up BIOS and boot sequence properly for me? Sorry for inconvenience.
Thank you for your bug report. This issue was evaluated for inclusion
in the current release of Red Hat Enterprise Linux. Unfortunately, we
are unable to address this request in the current release. Because we
are in the final stage of Red Hat Enterprise Linux 6 development, only
significant, release-blocking issues involving serious regressions and
data corruption can be considered.
If you believe this issue meets the release blocking criteria as
defined and communicated to you by your Red Hat Support representative,
please ask your representative to file this issue as a blocker for the
current release. Otherwise, ask that it be evaluated for inclusion in
the next minor release of Red Hat Enterprise Linux.
we have set BIOS to "OS Control" and it works as suggested. Now acpi_cpufreq kernel module is used instead of p4-clockmod and
I'm going to close this ticket.
Thanks for your help!