BUG: at kernel/sched.c:4031 __schedule()

BUG: at kernel/sched.c:4031 __schedule()

[Oleg Kechin]

Hi
I run 2.6.20-rt8 kernel on board like innovator1510 (OMAP5910 cpu)
I notice in boot string:
BUG: at kernel/sched.c:4031 __schedule()
kernel complain interrupts are enabled after schedule.

digging in sched.c I figured out that interrupts are disabled when cpu 
enter __sched(),
but are enabled when it went out.
Playing with the code i can find out, that problem is in the next 
fragment: (line 4024)

    if (likely(prev != next)) {
        next->timestamp = now;
        rq->nr_switches++;
        rq->curr = next;
        ++*switch_count;

        prepare_task_switch(rq, next);
        prev = context_switch(rq, prev, next);
        barrier();
        trace_special_pid(prev->pid, PRIO(prev), PRIO(current));
        /*
         * this_rq must be evaluated again because prev may have moved
         * CPUs since it called schedule(), thus the 'rq' on its stack
         * frame will be invalid.
         */
        finish_task_switch(this_rq(), prev);
        __preempt_enable_no_resched();
    } else {

in prepare_task_switch(rq, next); interrupts are enabled,
but in finish_task_switch(this_rq(), prev); interrupts not disabled
(it look not symmetrical for me).

Can anybody tell - is this right behavior?
I think interrupts should be disabled somewhere in this fragment,
or may be, scheduler should not complain?

Oleg Kechin.

Re: BUG: at kernel/sched.c:4031 __schedule()

[Dirk Behme]

Oleg Kechin wrote:
> Hi
> I run 2.6.20-rt8 kernel on board like innovator1510 (OMAP5910 cpu)
> I notice in boot string:
> BUG: at kernel/sched.c:4031 __schedule()
> kernel complain interrupts are enabled after schedule.
> 
> digging in sched.c I figured out that interrupts are disabled when cpu 
> enter __sched(),
> but are enabled when it went out.
> Playing with the code i can find out, that problem is in the next 
> fragment: (line 4024)
> 
>    if (likely(prev != next)) {
>        next->timestamp = now;
>        rq->nr_switches++;
>        rq->curr = next;
>        ++*switch_count;
> 
>        prepare_task_switch(rq, next);
>        prev = context_switch(rq, prev, next);
>        barrier();
>        trace_special_pid(prev->pid, PRIO(prev), PRIO(current));
>        /*
>         * this_rq must be evaluated again because prev may have moved
>         * CPUs since it called schedule(), thus the 'rq' on its stack
>         * frame will be invalid.
>         */
>        finish_task_switch(this_rq(), prev);
>        __preempt_enable_no_resched();
>    } else {
> 
> in prepare_task_switch(rq, next); interrupts are enabled,
> but in finish_task_switch(this_rq(), prev); interrupts not disabled
> (it look not symmetrical for me).
> 
> Can anybody tell - is this right behavior?
> I think interrupts should be disabled somewhere in this fragment,
> or may be, scheduler should not complain?

Looks to me that this isn't an OMAP specific question. I 
think linux-rt-users@vger.kernel.org list [1] is a better 
place for this question.

Did you try a more recent -rt patch? They are updated 
frequently with additional fixes.

Regards

Dirk

[1] http://rt.wiki.kernel.org/index.php/Mailinglists