diff mbox

[1/3] acpi: check _PSS invalidation when BIOS report _PSS with 0x80000000

Message ID 20090525110152.GA31474@srcf.ucam.org (mailing list archive)
State Superseded, archived
Headers show

Commit Message

Matthew Garrett May 25, 2009, 11:01 a.m. UTC
On Thu, May 14, 2009 at 01:35:10PM -0400, Len Brown wrote:
> NAK
> 
> This is a recording.
> 
> Andrew, please remove this patch from your series
> per issues earlier discussed on the list.

On the dump I have from a machine showing this issue, we'd fail 
gracefully if we checked the return value of 
acpi_processor_preregister_performance() as the coordination type is set 
to an invalid value. Are there any cases where this fails and the 
hardware still works? If not, then:

would seem to be correct. The alternative is that the number of 
processors is also set to 0x80000000 - according to the spec "OSPM will 
not start performing power state transitions to a particular P-state 
until this number of processors belonging to the same domain have been 
detected and started". Since we're clearly never reaching that 
condition, why is the governor even getting started?
diff mbox

Patch

diff --git a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
index 208ecf6..fbb8e59 100644
--- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -561,7 +561,11 @@  static int __init acpi_cpufreq_early_init(void)
 	}
 
 	/* Do initialization in ACPI core */
-	acpi_processor_preregister_performance(acpi_perf_data);
+	if (acpi_processor_preregister_performance(acpi_perf_data)) {
+		free_acpi_perf_data();
+		return -EINVAL;
+	}
+
 	return 0;
 }