Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 489580

Summary: when booted with P-state limit, limit can never be increased
Product: Red Hat Enterprise Linux 4 Reporter: Marc Milgram <mmilgram>
Component: kernelAssignee: Prarit Bhargava <prarit>
Status: CLOSED WONTFIX QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: high    
Version: 4.7CC: coughlan, dhoward, jplans, kzhang, plyons, tao, vgoyal
Target Milestone: rcKeywords: Patch, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 489566 Environment:
Last Closed: 2010-10-18 12:36:09 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:
Attachments:
Description Flags
Possible fix none

Comment 1 Marc Milgram 2009-03-12 13:47:57 UTC 
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):
5.3

How reproducible:
Always

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)  

There is an upstream git commit that should fix this:

http://mirror.celinuxforum.org/gitstat/commit-detail.php?commit=22c970f3468a6766b362d57fa32ebb92cb8cd6db
Comment 2 RHEL Program Management 2009-03-12 18:56:50 UTC 
Since RHEL 4.8 External Beta has begun, and this bugzilla remains 
unresolved, it has been rejected as it is not proposed as exception or 
blocker.
Comment 3 Prarit Bhargava 2009-03-16 15:39:18 UTC 
Not a regression, too late for RHEL4.8.

P.
Comment 4 RHEL Program Management 2009-03-16 15:55:56 UTC 
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.
Comment 5 Marc Milgram 2009-03-16 17:42:36 UTC 
Please review this for inclusion in 4.9.
Comment 12 Prarit Bhargava 2010-10-18 12:35:07 UTC 
CPU Frequency (cpufreq) is used by a large number of systems.  The issue
is that this patch enables new functionality in a final release of a
RHEL stream.

The code in the suggested patch was evaluated by RH engineering, and
requires a signficant test cycle for RHEL4.9.   One of RH's principles
in accepting a patch is the stability of the patch and since this patch
effects a large number of systems we cannot accept it for RHEL4.9.

In addition, the BZ is marked a blocker when in fact this is NOT a
regression.  It is likely the blocker flag was carried over from the
clone of the RHEL5 bug.