From patchwork Mon May 25 11:01:52 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Garrett X-Patchwork-Id: 25798 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n4PB29SG032421 for ; Mon, 25 May 2009 11:02:09 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751765AbZEYLCF (ORCPT ); Mon, 25 May 2009 07:02:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751732AbZEYLCF (ORCPT ); Mon, 25 May 2009 07:02:05 -0400 Received: from cavan.codon.org.uk ([93.93.128.6]:40709 "EHLO vavatch.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751375AbZEYLCE (ORCPT ); Mon, 25 May 2009 07:02:04 -0400 Received: from mjg59 by vavatch.codon.org.uk with local (Exim 4.69) (envelope-from ) id 1M8XwG-0008Cr-Ji; Mon, 25 May 2009 12:01:52 +0100 Date: Mon, 25 May 2009 12:01:52 +0100 From: Matthew Garrett To: Len Brown Cc: akpm@linux-foundation.org, linux-acpi@vger.kernel.org, youquan.song@intel.com, venkatesh.pallipadi@intel.com Subject: Re: [patch 1/3] acpi: check _PSS invalidation when BIOS report _PSS with 0x80000000 Message-ID: <20090525110152.GA31474@srcf.ucam.org> References: <200905122054.n4CKsfa3001669@imap1.linux-foundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: mjg59@codon.org.uk X-SA-Exim-Scanned: No (on vavatch.codon.org.uk); SAEximRunCond expanded to false Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org 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 --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; }