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
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.
Not a regression, too late for RHEL4.8. P.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Please review this for inclusion in 4.9.
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.