Bug 489566 - when booted with P-state limit, limit can never be increased
when booted with P-state limit, limit can never be increased
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Stanislaw Gruszka
Red Hat Kernel QE team
: ZStream
: 563344 (view as bug list)
Depends On:
Blocks: 533192 526775 540569 569727
  Show dependency treegraph
Reported: 2009-03-10 13:56 EDT by Marc Milgram
Modified: 2014-06-09 09:49 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 489580 (view as bug list)
Last Closed: 2010-03-30 03:39:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
RHEL5 patch (1.11 KB, patch)
2009-03-23 10:28 EDT, Prarit Bhargava
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0178 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.5 kernel security and bug fix update 2010-03-29 08:18:21 EDT

  None (edit)
Comment 1 Marc Milgram 2009-03-10 13:57:54 EDT
There is an upstream git commit that should fix this:

Comment 2 Marc Milgram 2009-03-12 09:44:58 EDT
Sanitized description:

Certain modern servers contain BIOS functionality to set a P-State limit. This works by generating an ACPI_PROCESSOR_NOTIFY_PERFORMANCE event and re-reading the APCI _PPC object.  _PPC indicates the smallest index (highest frequency) that the OS is allowed to select.

In general, this works fine under EL5.3. But if the cpufreq driver
(acpi-cpufreq) initializes while the _PPC object is already active (_PPC > 0),
the max frequency limit is set such that it can't be changed to normal when a
new ACPI_PROCESSOR_NOTIFY_PERFORMANCE event arrives and _PPC is set back to 0.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. reboot, or (rmmod acpi-cpufreq; modprobe acpi-cpufreq) while power
consumption is set to "minimum power".
2. change power setting to "max performance"

Actual results:
scaling_max_freq is still set to the frequency corresponding to "minimum power"

Expected results:
scaling_max_freq is set to maximum (=cpuinfo_max_freq)
Comment 4 Prarit Bhargava 2009-03-20 07:27:37 EDT
Do we have one of these systems in RHTS?

Comment 10 Prarit Bhargava 2009-03-23 10:28:55 EDT
Created attachment 336296 [details]
RHEL5 patch
Comment 12 Stanislaw Gruszka 2009-05-06 11:41:09 EDT
Brew build for test kernel packages with this bug and BZ494288 fixes are here:

Comment 16 Stanislaw Gruszka 2009-06-24 07:50:28 EDT
To reproduce this bug is crucial to set "Minimum power" and "Apply" in iRMC webpage _after_ reboot console command. If we first change power settings and then reboot machine everything works just fine.
Comment 17 Stanislaw Gruszka 2009-06-26 02:35:10 EDT
Patch pointed by Marc in Comment #1 fix the bug. I tested it on machine (thanks Gary) and everything works. 

Looks kernel I build for customer to test in Comment #12 just not contain the patch. My bad, I probably forgot to commit change to git repo before building the rpm.

If You want to give kernel to customer for confirmation here is brew build:

Comment 18 RHEL Product and Program Management 2009-09-25 13:38:02 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 19 Don Zickus 2009-10-06 15:36:40 EDT
in kernel-2.6.18-168.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 21 Chris Ward 2010-02-11 05:21:13 EST
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~

RHEL 5.5 Beta has been released! There should be a fix present in this 
release that addresses your request. Please test and report back results 
here, by March 3rd 2010 (2010-03-03) or sooner.

Upon successful verification of this request, post your results and update 
the Verified field in Bugzilla with the appropriate value.

If you encounter any issues while testing, please describe them and set 
this bug into NEED_INFO. If you encounter new defects or have additional 
patch(es) to request for inclusion, please clone this bug per each request
and escalate through your support representative.
Comment 22 Gary Case 2010-03-01 17:48:47 EST
*** Bug 563344 has been marked as a duplicate of this bug. ***
Comment 31 errata-xmlrpc 2010-03-30 03:39:28 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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