Bug 626893 - Maximum available frequency on Xeon X3210 (2.13GHz) is 1600MHz when using p4-clockmod
Maximum available frequency on Xeon X3210 (2.13GHz) is 1600MHz when using p4...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cpuspeed (Show other bugs)
6.1
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: John Feeney
Red Hat Kernel QE team
: RHELNAK
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-24 12:36 EDT by Adam Okuliar
Modified: 2013-01-10 02:29 EST (History)
8 users (show)

See Also:
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".
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-25 10:54:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Okuliar 2010-08-24 12:36:53 EDT
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):
RHEL6.0-20100818.0_nfs-Server-x86_64
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 15:57:05 EDT
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.

Barry
Comment 3 Matthew Garrett 2010-08-24 16:42:13 EDT
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 16:56:06 EDT
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.

Thanks
Jirka
Comment 5 Matthew Garrett 2010-08-24 17:01:29 EDT
    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 17:03:59 EDT
Jirka,

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-24 22:48:09 EDT
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

Barry
Comment 10 Adam Okuliar 2010-08-25 03:56:18 EDT
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.

Adam
Comment 12 RHEL Product and Program Management 2010-08-25 09:48:20 EDT
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 11:50:44 EDT
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
2132000

I'm going to close this ticket.

Thanks for your help!
Jirka

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