Bug 626893
Summary: | Maximum available frequency on Xeon X3210 (2.13GHz) is 1600MHz when using p4-clockmod | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Adam Okuliar <aokuliar> |
Component: | cpuspeed | Assignee: | John Feeney <jfeeney> |
Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.1 | CC: | aokuliar, benl, bmarson, dshaks, jhladky, peterm, sdenham, syeghiay |
Target Milestone: | rc | Keywords: | RHELNAK |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
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 14:54:43 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Adam Okuliar
2010-08-24 16:36:53 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. Barry 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 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 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". 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. 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 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 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. 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 |