RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 626893 - Maximum available frequency on Xeon X3210 (2.13GHz) is 1600MHz when using p4-clockmod
Summary: Maximum available frequency on Xeon X3210 (2.13GHz) is 1600MHz when using p4...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cpuspeed
Version: 6.1
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: John Feeney
QA Contact: Red Hat Kernel QE team
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-24 16:36 UTC by Adam Okuliar
Modified: 2013-01-10 07:29 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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".
Clone Of:
Last Closed: 2010-08-25 14:54:43 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Adam Okuliar 2010-08-24 16:36:53 UTC
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
Actual results:
cpuinfo_max_freq is only 1600Mhz on 2130MHz CPU

Expected results:
Correct value of maximum CPU frequency in /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq

Comment 2 Barry Marson 2010-08-24 19:57:05 UTC
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.


Comment 3 Matthew Garrett 2010-08-24 20:42:13 UTC
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

Comment 4 Jiri Hladky 2010-08-24 20:56:06 UTC
Hi Barry,
hi Matt,

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.


Comment 5 Matthew Garrett 2010-08-24 21:01:29 UTC
    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.
    New Contents:
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".

Comment 6 Matthew Garrett 2010-08-24 21:03:59 UTC

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.

Comment 9 Barry Marson 2010-08-25 02:48:09 UTC
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


Comment 10 Adam Okuliar 2010-08-25 07:56:18 UTC
Hi Guys

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.


Comment 12 RHEL Program Management 2010-08-25 13:48:20 UTC
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.

Comment 14 Jiri Hladky 2010-08-25 15:50:44 UTC
Hi Matt,

we have set BIOS to "OS Control" and it works as suggested. Now acpi_cpufreq kernel module is used instead of p4-clockmod and 

$more /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
reports correctly

I'm going to close this ticket.

Thanks for your help!

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