Bug 489566 - when booted with P-state limit, limit can never be increased
Summary: when booted with P-state limit, limit can never be increased
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Stanislaw Gruszka
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
: 563344 (view as bug list)
Depends On:
Blocks: 526775 533192 540569 569727
TreeView+ depends on / blocked
 
Reported: 2009-03-10 17:56 UTC by Marc Milgram
Modified: 2018-10-27 14:27 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 489580 (view as bug list)
Environment:
Last Closed: 2010-03-30 07:39:28 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0178 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.5 kernel security and bug fix update 2010-03-29 12:18:21 UTC

Comment 1 Marc Milgram 2009-03-10 17:57:54 UTC
There is an upstream git commit that should fix this:

http://mirror.celinuxforum.org/gitstat/commit-detail.php?commit=22c970f3468a6766b362d57fa32ebb92cb8cd6db

Comment 2 Marc Milgram 2009-03-12 13:44:58 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)

Comment 4 Prarit Bhargava 2009-03-20 11:27:37 UTC
Do we have one of these systems in RHTS?

P.

Comment 10 Prarit Bhargava 2009-03-23 14:28:55 UTC
Created attachment 336296 [details]
RHEL5 patch

Comment 12 Stanislaw Gruszka 2009-05-06 15:41:09 UTC
Brew build for test kernel packages with this bug and BZ494288 fixes are here:

https://brewweb.devel.redhat.com/taskinfo?taskID=1788615

Comment 16 Stanislaw Gruszka 2009-06-24 11:50:28 UTC
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 06:35:10 UTC
Patch pointed by Marc in Comment #1 fix the bug. I tested it on 10.33.8.173 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:

https://brewweb.devel.redhat.com/taskinfo?taskID=1861439

Comment 18 RHEL Program Management 2009-09-25 17:38:02 UTC
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
release.

Comment 19 Don Zickus 2009-10-06 19:36:40 UTC
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 10:21:13 UTC
~~ 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 22:48:47 UTC
*** Bug 563344 has been marked as a duplicate of this bug. ***

Comment 31 errata-xmlrpc 2010-03-30 07:39:28 UTC
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.

http://rhn.redhat.com/errata/RHSA-2010-0178.html


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