Skip to contentSkip to conversation

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

DISCUSSION Oleg Kechin 2 participants 2 messages Apr 6, 2007 – Apr 7, 2007

lore
Share & tools
lore
#0 lore raw

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.

#1 lore raw
Quoted 29 lines · 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 {

Quoted 7 lines

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 [email protected] 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