From patchwork Fri Sep 20 05:26:12 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yinghai Lu X-Patchwork-Id: 2915171 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id AA94A9F1E2 for ; Fri, 20 Sep 2013 05:26:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id ABB3A20319 for ; Fri, 20 Sep 2013 05:26:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CA9EF20295 for ; Fri, 20 Sep 2013 05:26:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753305Ab3ITF0c (ORCPT ); Fri, 20 Sep 2013 01:26:32 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:17096 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752729Ab3ITF0b (ORCPT ); Fri, 20 Sep 2013 01:26:31 -0400 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8K5QPDj021786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Sep 2013 05:26:25 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8K5QKk6021900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Sep 2013 05:26:21 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8K5QKul004655; Fri, 20 Sep 2013 05:26:20 GMT Received: from linux-siqj.site (/10.159.242.39) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Sep 2013 22:26:20 -0700 From: Yinghai Lu To: "Rafael J. Wysocki" , Viresh Kumar Cc: cpufreq@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Yinghai Lu Subject: [PATCH] cpufreq: skip loading acpi_cpufreq after intel_pstate Date: Thu, 19 Sep 2013 22:26:12 -0700 Message-Id: <1379654772-10700-1-git-send-email-yinghai@kernel.org> X-Mailer: git-send-email 1.8.1.4 X-Source-IP: acsinet21.oracle.com [141.146.126.237] Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP If the hw support intel_pstate and acpi_cpufreq, intel_pstate will get loaded at first. acpi_cpufreq_init will call acpi_cpufreq_early_init() and it allocate perf data and init those perf data in ACPI core, (that will go over all cpus). but late it will free them as cpufreq_register_driver(acpi_cpufreq) will return fail as init_pstate already take over before. Use cpufreq_get_current_driver() to check if we can skip the acpi_cpufreq loading. Also there is racing in __acpi_processor_start ==> acpi_processor_load_module ==> request_module_nowait/requested = 1 before first pr path to have requested set, second cpu would request again. that will cause acpi_cpufreq_early_init to be called in parallel. that is cause for intermittent crashes. So add mutex to protect it. Signed-off-by: Yinghai Lu --- drivers/acpi/processor_perflib.c | 8 +++++++- drivers/cpufreq/acpi-cpufreq.c | 4 ++++ 2 files changed, 11 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux-2.6/drivers/cpufreq/acpi-cpufreq.c =================================================================== --- linux-2.6.orig/drivers/cpufreq/acpi-cpufreq.c +++ linux-2.6/drivers/cpufreq/acpi-cpufreq.c @@ -986,6 +986,10 @@ static int __init acpi_cpufreq_init(void { int ret; + /* don't keep reloading if cpufreq_driver exists */ + if (cpufreq_get_current_driver()) + return 0; + if (acpi_disabled) return 0; Index: linux-2.6/drivers/acpi/processor_perflib.c =================================================================== --- linux-2.6.orig/drivers/acpi/processor_perflib.c +++ linux-2.6/drivers/acpi/processor_perflib.c @@ -235,6 +235,7 @@ void acpi_processor_ppc_exit(void) acpi_processor_ppc_status &= ~PPC_REGISTERED; } +static DEFINE_MUTEX(acpi_cpufreq_load_lock); /* * Do a quick check if the systems looks like it should use ACPI * cpufreq. We look at a _PCT method being available, but don't @@ -246,8 +247,12 @@ void acpi_processor_load_module(struct a acpi_status status = 0; struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; - if (!arch_has_acpi_pdc() || requested) + mutex_lock(&acpi_cpufreq_load_lock); + if (!arch_has_acpi_pdc() || requested ||cpufreq_get_current_driver()) { + mutex_unlock(&acpi_cpufreq_load_lock); return; + } + status = acpi_evaluate_object(pr->handle, "_PCT", NULL, &buffer); if (!ACPI_FAILURE(status)) { printk(KERN_INFO PREFIX "Requesting acpi_cpufreq\n"); @@ -255,6 +260,7 @@ void acpi_processor_load_module(struct a requested = 1; } kfree(buffer.pointer); + mutex_unlock(&acpi_cpufreq_load_lock); } static int acpi_processor_get_performance_control(struct acpi_processor *pr)