[lkml]   [2002]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] kernel BUG at sched.c:944! only with CONFIG_PREEMPT=y]
Ingo Molnar wrote:
> On 12 Sep 2002, Robert Love wrote:
> > While this sounds like a great debugging check, it is not useful in
> > general since we surely have some bad code that calls schedule() with
> > locks held. Further, since the atomic accounting only includes locks if
> > CONFIG_PREEMPT is set, you only see this with kernel preemption enabled.
> it *is* a great debugging check, at zero added cost. Scheduling from an
> atomic region *is* a critical bug that can and will cause problems in 99%
> of the cases. Rather fix the asserts that got triggered instead of backing
> out useful debugging checks ...

The problem here is that some random piece of code has bumped
the preemption counter, and we've lost all trace of that at
the site where the problem is detected.

So... In do_initcalls() we'd need:

do {
+ if (in_atomic())
+ printk("initcall at %p is buggy\n", call);
} while (call < &__initcall_end);

and to diagnose this particular problem I guess we need to

if (in_atomic())
printk("goofed at %d\n", __LINE__);

to twenty or so places in start_kernel().
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.052 / U:1.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site