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 {
(*call)();
+ if (in_atomic())
+ printk("initcall at %p is buggy\n", call);
call++;
} while (call < &__initcall_end);
and to diagnose this particular problem I guess we need to
add
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 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/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:30 EST