From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: linux-next: Tree for Feb 8 [ smp|cpufreq: WARNING: at kernel/smp.c:245 smp_call_function_single ] Date: Fri, 8 Feb 2013 14:58:01 +0100 Message-ID: <20130208135801.GA30334@gmail.com> References: <2612804.Hcyse1lRVO@vostro.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-ee0-f47.google.com ([74.125.83.47]:57223 "EHLO mail-ee0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757096Ab3BHN6I (ORCPT ); Fri, 8 Feb 2013 08:58:08 -0500 Content-Disposition: inline In-Reply-To: <2612804.Hcyse1lRVO@vostro.rjw.lan> Sender: linux-next-owner@vger.kernel.org List-ID: To: "Rafael J. Wysocki" Cc: sedat.dilek@gmail.com, Hillf Danton , Stephen Rothwell , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Linux ACPI , Linux PM List , x86@kernel.org, Ingo Molnar , Chuansheng Liu * Rafael J. Wysocki wrote: > On Friday, February 08, 2013 01:47:44 PM Sedat Dilek wrote: > > On Fri, Feb 8, 2013 at 12:53 PM, Hillf Danton wrote: > > > Hello Sedat > > > > > > On Fri, Feb 8, 2013 at 4:46 PM, Sedat Dilek wrote: > > >> On Fri, Feb 8, 2013 at 5:31 AM, Stephen Rothwell wrote: > > >> With today's Linux-Next I see this warning: > > >> > > >> [ 0.377442] ------------[ cut here ]------------ > > >> [ 0.377452] WARNING: at kernel/smp.c:245 > > >> smp_call_function_single+0x146/0x190() > > >> [ 0.377455] Hardware name: 530U3BI/530U4BI/530U4BH > > >> [ 0.377458] Modules linked in: > > >> [ 0.377463] Pid: 1, comm: swapper/0 Not tainted > > >> 3.8.0-rc6-next20130208-1-iniza-small #1 > > >> [ 0.377467] Call Trace: > > >> [ 0.377473] [] warn_slowpath_common+0x7f/0xc0 > > >> [ 0.377479] [] ? acpi_cpufreq_target+0x2c0/0x2c0 > > >> [ 0.377483] [] warn_slowpath_null+0x1a/0x20 > > >> [ 0.377487] [] smp_call_function_single+0x146/0x190 > > >> [ 0.377492] [] ? acpi_cpufreq_target+0x2c0/0x2c0 > > >> [ 0.377496] [] smp_call_function_any+0x51/0x100 > > >> [ 0.377500] [] get_cur_val+0x99/0x130 > > >> [ 0.377504] [] ? acpi_cpufreq_cpu_init+0x2b4/0x6a0 > > >> [ 0.377508] [] get_cur_freq_on_cpu+0x60/0x80 > > >> [ 0.377512] [] acpi_cpufreq_cpu_init+0x412/0x6a0 > > >> [ 0.377517] [] cpufreq_add_dev+0x2d9/0x4f0 > > >> [ 0.377523] [] ? cpufreq_gov_dbs_init+0x2c/0x2c > > >> [ 0.377528] [] subsys_interface_register+0x89/0xd0 > > >> [ 0.377533] [] cpufreq_register_driver+0x8e/0x180 > > >> [ 0.377537] [] acpi_cpufreq_init+0xf6/0x1f8 > > >> [ 0.377542] [] ? platform_driver_register+0x46/0x50 > > >> [ 0.377547] [] do_one_initcall+0x3f/0x170 > > >> [ 0.377553] [] kernel_init_freeable+0x13e/0x1cd > > >> [ 0.377560] [] ? do_early_param+0x86/0x86 > > >> [ 0.377565] [] ? rest_init+0x80/0x80 > > >> [ 0.377569] [] kernel_init+0xe/0xf0 > > >> [ 0.377575] [] ret_from_fork+0x7c/0xb0 > > >> [ 0.377578] [] ? rest_init+0x80/0x80 > > >> [ 0.377581] ---[ end trace c6ec8280ce20313a ]--- > > >> > > >> kernel/smp.c: Line #245 see [1]. > > >> > > > Can you please try the following? > > > > > > --- a/kernel/smp.c Fri Feb 8 19:25:32 2013 > > > +++ b/kernel/smp.c Fri Feb 8 19:53:14 2013 > > > @@ -241,7 +241,7 @@ int smp_call_function_single(int cpu, sm > > > * send smp call function interrupt to this cpu and as such deadlocks > > > * can't happen. > > > */ > > > - WARN_ON_ONCE(cpu_online(this_cpu) && (irqs_disabled() || in_interrupt()) > > > + WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() > > > && !oops_in_progress); > > > > > > if (cpu == this_cpu) { > > > -- > > > > NO, it doesn't. > > > > So, you want to partly revert... > > > > commit b29f39c7c3e75a741a7da88244ec707f293ec04c > > "smp: Give WARN()ing if in_interrupt() when calling > > smp_call_function_many()/single()" > > > > ...why not completely? > > > > This patch was in last days Linux-Next and did not cause troubles (AFAICS). > > This problem was introduced by some cpufreq changes that have > been dropped from linux-next for now (they are still present > in the one you're testing, though). SMP cross-calls from IRQ context are generally unsafe, so I'd suggest a good look at the cpufreq changes first, before reverting the stronger debugging we introduced. Thanks, Ingo