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:
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;
}
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?
--
Matthew Garrett | mjg59@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
