http://bugzilla.kernel.org/show_bug.cgi?id=15174
Summary: powernow-k8: _PSS sanity check prevents CPU clock
scaling
Product: ACPI
Version: 2.5
Kernel Version: 2.6.30
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Config-Tables
AssignedTo: acpi_config-tab...@kernel-bugs.osdl.org
ReportedBy: h...@mimosa.com
CC: h...@mimosa.com
Regression: Yes
Created an attachment (id=24785)
--> (http://bugzilla.kernel.org/attachment.cgi?id=24785)
dmesg output from 2.6.18-128.7.1.el5 -- scaling worked
[Originally reported https://bugzilla.redhat.com/show_bug.cgi?id=559357 and
https://www.centos.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=22341&forum=44]
A new sanity check was added to linux/drivers/acpi/processor_perflib.c
acpi_processor_get_performance_states. The commit is
34d531e640cb805973cf656b15c716b961565cea "ACPI: sanity check _PSS frequency to
prevent cpufreq crash"
This new check says that if any _PSS table freq entry is impossibly large (i.e.
the frequency, expressed in kHz, would not fit in a u32), the whole table will
be ignored.
Unfortunately, my machine's BIOS has some such entries. It also has sane
entries. Before the patch, my system was stable and could do CPU frequency
scaling. After the patch, my system cannot do CPU frequency scaling.
These crazy _PSS values used to be ignored without ignoring the reasonable
ones. The ignoring was done in several routines in cpu/cpufreq/powernow-k8.c,
but not acpi_processor_get_performance_states. The patch must have been made
because bad values were not ignored somewhere imporant.
My machine is an HP Pavilion a530n with a stock 3.11 BIOS (the latest on HP's
support page; dated September 2004). The machine has worked well in Linux all
the years since then.
http://h10025.www1.hp.com/ewfrf/wc/softwareDownloadIndex?softwareitem=pv-22976-2&lc=en&dlc=en&cc=ca&lang=en&os=228&product=404646
My system runs CentOS x86_64 kernels. The problem appeared in the transition
from kernel-2.6.18-128.7.1.el5 to kernel-2.6.18-164.el5. I have tracked it
down to the commit that was accepted in the Mainline 2.6.30.
My hope would be that the sanity checker could be changed to reject bad table
entries but preserve any good ones.
Without the patch, dmesg shows:
powernow-k8: Pre-initialization of ACPI failed
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3200+ processors (1 cpu cores)
(version 2.20.00)
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: 0 : fid 0xc (2000 MHz), vid 0x2
powernow-k8: 1 : fid 0xa (1800 MHz), vid 0x6
powernow-k8: 2 : fid 0x0 (800 MHz), vid 0xa
powernow-k8: ph2 null fid transition 0xc
With the patch:
powernow-k8: Pre-initialization of ACPI failed
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3200+ processors (1 cpu cores)
(version 2.20.00)
ACPI: Invalid BIOS _PSS frequency: 0x9999999 MHz
powernow-k8: BIOS error: maxvid exceeded with pstate 2
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
