Re: 2.5 Problem Status Report

[Ingo Molnar]

On Wed, 11 Sep 2002, Oleg Drokin wrote:

> > >    BUG at kernel/sched.c        open                  10 Sep 2002
> > What exactly is this?
> 
> Looks like this is my bugreport for BUG in kernel/sched.c:944 in the middle
> of partition parsing output on boot.
> 
> Subject of email was
> '2.5.34 BUG at kernel/sched.c:944 (partitions code related?)'
> msgid: [e-mail]

very strange backtrace:

 >>EIP; c0115818 <schedule+18/4a0>   <=====
 Trace; c01053a0 <default_idle+0/40>
 Trace; c0105000 <_stext+0/0>
 Trace; c01053c8 <default_idle+28/40>
 Trace; c010547e <cpu_idle+4e/50>
 Trace; c010506c <rest_init+6c/70>

i've once seen the 2.5 IDE code doing a schedule_timeout() from an IRQ
handler, but the above has to be something else. Could you hack sched.c to
print out the exact preemption count? It could be a preempt-count
underflow due to an unbalanced spin_unlock, or an inbalanced
preempt_enable. [or the IRQ code - but i doubt that, we'd have seen
problems much earlier if this was the case.]

Oleg, do you have CONFIG_DEBUG_SPINLOCK enabled? That should catch an
unbalanced spin_unlock().

Robert, i'd suggest to add some sort of debugging code for this anyway, if
preempt_count goes below 0, right now we do this:

 #define dec_preempt_count() \
 do { \
         preempt_count()--; \
 } while (0)

this should be something like:

 #if CONFIG_DEBUG_SPINLOCK

 #define dec_preempt_count() \
 do { \
         if (!--preempt_count()) \
                 BUG(); \
 } while (0)

 #else

 #define dec_preempt_count() \
 do { \
         preempt_count()--; \
 } while (0)

 #endif

or introduce a separate debug config option, CONFIG_DEBUG_PREEMPT - until
all code is converted. This should catch a bad preempt_enable where it
happens.

	Ingo