This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Wed May 15 15:37:37 2024 Envelope-to: j@jasper.es Delivery-date: Wed, 18 Sep 2013 23:31:13 +0200 Received: from localhost ([127.0.0.1] helo=squeeze.vs19.net) by squeeze.vs19.net with esmtp (Exim 4.80) (envelope-from ) id 1VMPL7-0001Hk-7s for j@jasper.es; Wed, 18 Sep 2013 23:31:13 +0200 Original-Recipient: rfc822;jasper@telfort.nl Received: from pop3.telfort.nl [213.75.3.52] by squeeze.vs19.net with POP3 (fetchmail-6.3.21) for (single-drop); Wed, 18 Sep 2013 23:31:13 +0200 (CEST) Received: from cpxmta-msg05.kpnxchange.com (10.94.114.26) by cpxmbs-msg01.support.local (8.6.060.30) id 522FAFB8005AC0EB for jasper@telfort.nl; Wed, 18 Sep 2013 23:21:58 +0200 Received: from cpsmtpb-ews07.kpnxchange.com (213.75.39.10) by cpxmta-msg05.kpnxchange.com (8.6.060.14) id 522FB3AE00E1F3CB for jasper@telfort.nl; Wed, 18 Sep 2013 23:21:58 +0200 Received: from cpsps-ews12.kpnxchange.com ([10.94.84.179]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 18 Sep 2013 23:21:58 +0200 Received: from vger.kernel.org ([209.132.180.67]) by cpsps-ews12.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 18 Sep 2013 23:21:58 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753757Ab3IRVVr (ORCPT ); Wed, 18 Sep 2013 17:21:47 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:58116 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752117Ab3IRVVq convert rfc822-to-8bit (ORCPT ); Wed, 18 Sep 2013 17:21: Received: by mail-ob0-f170.google.com with SMTP id va2so8455005obc.15 for ; Wed, 18 Sep 2013 14:21:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=uJe7pUPslqtWgLtfWbqCRAGhZGTsgDd5SMcW4viAaUo=; X-Gm-Message-State: ALoCoQkJWS9wZu4tpKlrd6aP7oYeqIxYeql76orc3RZGH0/Mz6jTx37xx9d36Goc2jmDgfVtguxH Mime-Version: 1.0 X-Received: by 10.60.124.14 with SMTP id me14mr35656368oeb.4.1379539305535; Wed, 18 Sep 2013 14:21:45 -0700 (PDT) Received: by 10.182.145.8 with HTTP; Wed, 18 Sep 2013 14:21:45 -0700 (PDT) Date: Wed, 18 Sep 2013 23:21:45 +0200 Message-Id: Subject: Regression on cpufreq in v3.12-rc1 From: Linus Walleij To: "linux-kernel@vger.kernel.org" , "Rafael J. Wysocki" , Viresh Kumar Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 18 Sep 2013 21:21:58.0154 (UTC) FILETIME=[1B5DDEA0:01CEB4B5] X-RcptDomain: telfort.nl Hi Rafael, Viresh, I'm seeing this problem and maybe you can help me out fixing it properly: On some machines like the StrongARM SA1100 it seems that cpufreq_get() can be called before the cpufreq driver and thus the policy is set, resulting in a crash like this: ------------[ cut here ]------------ kernel BUG at /home/linus/linux/drivers/cpufreq/cpufreq.c:80! Internal error: Oops - BUG: 0 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc1-00001-g1266dae-dirty #17 task: c1830000 ti: c1832000 task.ti: c1832000 (...) Backtrace: [] (lock_policy_rwsem_read+0x0/0x48) from [] (cpufreq_get+0x34/0x68) [] (cpufreq_get+0x0/0x68) from [] (sa1100fb_activate_var+0xdc/0x3ac) r5:00000003 r4:0000000a [] (sa1100fb_activate_var+0x0/0x3ac) from [] (sa1100fb_set_par+0xa0/0xa8) [] (sa1100fb_set_par+0x0/0xa8) from [] (fbcon_init+0x444/0x4a8) r4:c1803200 [] (fbcon_init+0x0/0x4a8) from [] (visual_init+0x78/0xc8) [] (visual_init+0x0/0xc8) from [] (do_bind_con_driver+0x160/0x310) This bug comes from the framebuffer but I first encountered it in the PCMCIA driver, and both seem to cause the bug. In the past I think things worked smoothly: the consumers calling cpufreq_get() too early would just get 0 back. (Or so it seems to me.) The BUG() statement causing it is in the lock_policy_rwsem_##mode(int cpu) macro. Applying a patch like this seems to fix the issue: diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 43c24aa..4977b4b 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -70,7 +70,8 @@ static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem); static int lock_policy_rwsem_##mode(int cpu) \ { \ struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); \ - BUG_ON(!policy); \ + if(!policy) \ + return 0; \ down_##mode(&per_cpu(cpu_policy_rwsem, policy->cpu)); \ \ return 0; \ @@ -83,7 +84,8 @@ lock_policy_rwsem(write, cpu); static void unlock_policy_rwsem_##mode(int cpu) \ { \ struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); \ - BUG_ON(!policy); \ + if(!policy) \ + return; \ up_##mode(&per_cpu(cpu_policy_rwsem, policy->cpu)); \ } @@ -1423,6 +1425,9 @@ static unsigned int __cpufreq_get(unsigned int cpu) struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); unsigned int ret_freq = 0; + if (!policy) + return ret_freq; + if (!cpufreq_driver->get) return ret_freq; I don't really know if this is the right solution at all, so please help me out here... if you want that patch I can send it once I understand this properly. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/