From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: BUG: scheduling while atomic: swapper/0/0x10000002 Date: Mon, 28 Nov 2011 14:06:37 +0100 Message-ID: <1322485597.2921.120.camel@twins> References: <4ED37B0A.2000705@cwi.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <4ED37B0A.2000705@cwi.nl> Sender: linux-kernel-owner@vger.kernel.org To: "Wouter M. Koolen" Cc: paulmck@linux.vnet.ibm.com, "linux-kernel@vger.kernel.org" , mingo@elte.hu, fweisbec@gmail.com, linux-acpi@vger.kernel.org List-Id: linux-acpi@vger.kernel.org On Mon, 2011-11-28 at 12:14 +0000, Wouter M. Koolen wrote: > Dear Paul and others, > > On vanilla kernel 3.1.3, I got the following during boot. > > BUG: scheduling while atomic: swapper/0/0x10000002 > no locks held by swapper/0. > Modules linked in: > Pid: 0, comm: swapper Not tainted 3.1.3.debug+ #32 > Call Trace: > [] __schedule_bug+0x60/0x65 > [] ? pidmap_init+0x84/0xc4 > [] __schedule+0x759/0x920 > [] ? pidmap_init+0x84/0xc4 > [] __cond_resched+0x25/0x40 > [] _cond_resched+0x2d/0x40 > [] kmem_cache_alloc_trace+0x4f/0x1d0 > [] pidmap_init+0x84/0xc4 > [] start_kernel+0x339/0x3bc > [] x86_64_start_reservations+0x132/0x136 > [] x86_64_start_kernel+0xf0/0xf7 > > A little googling revealed that patch [2] "rcu: Avoid having > just-onlined CPU resched itself when RCU is idle" > is supposed to address this issue. However, booting 3.1.3 with patch [2] > leads to three new "BUG: scheduling while atomic: swapper/0/0x10000002" > reports every boot. > > The exact blurb varies a little bit, but all backtraces seem ACPI > related. I include three examples below. Some old [4] and new [1,3] > similar threads exist, but without resolution as far as I can tell. > > The machine, a 2008 macbook 4.1, seems to be fine. > > Is this just noise (produced by overzealous debugging checks) that I > should safely ignore? If not, please let me know what I can do to help > track this down. Bah, looks like d86ee4809d0 ("sched: optimize cond_resched()") is broken, what's weird is that it only now shows up. We reset the preempt_count to 0 at sched_init()->init_idle(), which is way before pidmap_init(), loosing the PREEMPT_ACTIVE bit that would disable should_resched().