This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu May 16 02:02:32 2024 Envelope-to: j@jasper.es Delivery-date: Thu, 19 Sep 2013 00:31:21 +0200 Received: from localhost ([127.0.0.1] helo=squeeze.vs19.net) by squeeze.vs19.net with esmtp (Exim 4.80) (envelope-from ) id 1VMQHI-0002ip-Vc for j@jasper.es; Thu, 19 Sep 2013 00:31:21 +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); Thu, 19 Sep 2013 00:31:20 +0200 (CEST) Received: from cpxmta-msg01.kpnxchange.com (10.94.114.22) by cpxmbs-msg01.support.local (8.6.060.30) id 522FAFB8005B0D4C for jasper@telfort.nl; Thu, 19 Sep 2013 00:30:08 +0200 Received: from cpsmtpb-ews08.kpnxchange.com (213.75.39.13) by cpxmta-msg01.kpnxchange.com (8.6.060.14) id 522FB3CB00E2F6DF for jasper@telfort.nl; Thu, 19 Sep 2013 00:30:08 +0200 Received: from cpsps-ews14.kpnxchange.com ([10.94.84.181]) by cpsmtpb-ews08.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 19 Sep 2013 00:30:08 +0200 Received: from vger.kernel.org ([209.132.180.67]) by cpsps-ews14.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 19 Sep 2013 00:30:08 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752055Ab3IRW37 (ORCPT ); Wed, 18 Sep 2013 18:29:59 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:59471 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751570Ab3IRW36 (ORCPT ); Wed, 18 Sep 2013 18:29:58 -0400 Received: from 38.127.1.5 [38.127.1.5] (HELO vostro.rjw.lan) by serwer1319399.home.pl [79.96.170.134] with SMTP (IdeaSmtpServer v0.80) id 2907cccd9bd95544; Thu, 19 Sep 2013 00:29:56 +0200 From: "Rafael J. Wysocki" To: Linus Walleij Cc: "linux-kernel@vger.kernel.org" , Viresh Kumar , srivatsa.bhat@linux.vnet.ibm.com Subject: Re: Regression on cpufreq in v3.12-rc1 Date: Thu, 19 Sep 2013 00:41:09 +0200 Message-Id: <45987104.t6r4hvPgQn@vostro.rjw.lan> User-Agent: KMail/4.10.5 (Linux/3.11.0+; KDE/4.10.5; x86_64; ; ) In-Reply-To: References: Mime-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org X-OriginalArrivalTime: 18 Sep 2013 22:30:08.0560 (UTC) FILETIME=[A1704B00:01CEB4BE] X-RcptDomain: telfort.nl On Wednesday, September 18, 2013 11:21:45 PM Linus Walleij wrote: > 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: Did you try the current linux-next branch from my tree? Rafael > ------------[ 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 -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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/