public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Wouter M. Koolen" <W.M.Koolen-Wijkstra@cwi.nl>
Cc: paulmck@linux.vnet.ibm.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	mingo@elte.hu, fweisbec@gmail.com, linux-acpi@vger.kernel.org
Subject: Re: BUG: scheduling while atomic: swapper/0/0x10000002
Date: Mon, 28 Nov 2011 14:06:37 +0100	[thread overview]
Message-ID: <1322485597.2921.120.camel@twins> (raw)
In-Reply-To: <4ED37B0A.2000705@cwi.nl>

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:
> [<ffffffff814058de>] __schedule_bug+0x60/0x65
> [<ffffffff8189b85a>] ? pidmap_init+0x84/0xc4
> [<ffffffff8140a3d9>] __schedule+0x759/0x920
> [<ffffffff8189b85a>] ? pidmap_init+0x84/0xc4
> [<ffffffff8103d855>] __cond_resched+0x25/0x40
> [<ffffffff8140a61d>] _cond_resched+0x2d/0x40
> [<ffffffff811107df>] kmem_cache_alloc_trace+0x4f/0x1d0
> [<ffffffff8189b85a>] pidmap_init+0x84/0xc4
> [<ffffffff8188ab47>] start_kernel+0x339/0x3bc
> [<ffffffff8188a322>] x86_64_start_reservations+0x132/0x136
> [<ffffffff8188a416>] 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().

  reply	other threads:[~2011-11-28 13:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-28 12:14 BUG: scheduling while atomic: swapper/0/0x10000002 Wouter M. Koolen
2011-11-28 13:06 ` Peter Zijlstra [this message]
2012-01-10 15:10   ` Wouter M. Koolen
     [not found] <20100810140748.GA29878@fancy-poultry.org>
2010-08-10 14:29 ` Markus Trippelsdorf
2010-08-10 15:13   ` Sergey Senozhatsky
2010-08-10 15:19   ` Piotr Hosowicz
2010-08-10 15:35     ` Sergey Senozhatsky
2010-08-10 15:36       ` Piotr Hosowicz
  -- strict thread matches above, loose matches on Subject: below --
2010-08-10 12:38 Sergey Senozhatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1322485597.2921.120.camel@twins \
    --to=peterz@infradead.org \
    --cc=W.M.Koolen-Wijkstra@cwi.nl \
    --cc=fweisbec@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox