BUG: at kernel/sched.c:4031 __schedule()
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.
Quoted 1 line · Oleg Kechin
in
prepare_task_switch(rq, next); interrupts are enabled,
That's a bug. __schedule should not have interrupts enabled. What's the back trace of this?
-- Steve
Quoted 13 lines
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Quoted 4 lines
Quoted 1 line
in
prepare_task_switch(rq, next); interrupts are enabled,That's a bug.
__scheduleshould not have interrupts enabled. What's the back trace of this?
I've also seen this in the past. Interrupts are enabled in prepare_lock_switch because ARM defines __ARCH_WANT_INTERRUPTS_ON_CTXSW.
IIRC Thomas fixed this for the current -rt release.
Cheers,
Jan
Quoted 10 lines · Jan Altenberg
Hi,
Quoted 4 lines
Quoted 1 line
in
prepare_task_switch(rq, next); interrupts are enabled,That's a bug.
__scheduleshould not have interrupts enabled. What's the back trace of this?I've also seen this in the past. Interrupts are enabled in
prepare_lock_switchbecause ARM defines__ARCH_WANT_INTERRUPTS_ON_CTXSW.
Heh, silly me. I've been focused so much on x86 that I forgot what other archs do.
Quoted 1 line
IIRC Thomas fixed this for the current -rt release.
Thomas, perhaps you want to post the fix.
What arch is innovator1510 (OMAP5910 cpu) anyway?
/me has been away from embedded systems for some time.
-- Steve
Quoted 2 lines · Steven Rostedt
What arch is innovator1510 (OMAP5910 cpu) anyway?
It's an ARM .
Quoted 2 lines
/me has been away from embedded systems for some time.
The "fix" went into -rt6 , then was dropped in -rt7 .. I guess a better fix is being working on, not sure..
Daniel
Quoted 15 lines · Steven Rostedt
Quoted 10 lines · Jan Altenberg
Hi,
Quoted 4 lines
Quoted 1 line
in
prepare_task_switch(rq, next); interrupts are enabled,That's a bug.
__scheduleshould not have interrupts enabled. What's the back trace of this?I've also seen this in the past. Interrupts are enabled in
prepare_lock_switchbecause ARM defines__ARCH_WANT_INTERRUPTS_ON_CTXSW.Heh, silly me. I've been focused so much on x86 that I forgot what other archs do.
Quoted 7 lines
Quoted 1 line
IIRC Thomas fixed this for the current -rt release.
Thomas, perhaps you want to post the fix.
What arch is innovator1510 (OMAP5910 cpu) anyway?
/me has been away from embedded systems for some time.
I was wrong, I guess it's still in there .. Below I think..
+ *
+ * The new debugging code in __schedule() expects that interrupts
+ * are disabled across a switch_to. Need to investigate which
+ * consequences this has.
*/
-#if 0 // preempt_rt hack, because warn_on in shedule.c triggers +#ifndef CONFIG_PREEMPT_RT
#define __ARCH_WANT_INTERRUPTS_ON_CTXSW
#endif
Review
Quoted 12 lines · Daniel Walker
.
+ *
+ * The new debugging code in__schedule()expects that interrupts
+ * are disabled across aswitch_to. Need to investigate which
+ * consequences this has.
*/(quoted diff) +1
-1-#if 0 // preempt_rt hack, because warn_on in shedule.c triggers +#ifndef CONFIG_PREEMPT_RT #define __ARCH_WANT_INTERRUPTS_ON_CTXSW #endif
It is starting to look like a real fix now, thanks for updating it Thomas .
Daniel
Quoted 17 lines · Daniel Walker
Review
Quoted 12 lines · Daniel Walker
.
+ *
+ * The new debugging code in__schedule()expects that interrupts
+ * are disabled across aswitch_to. Need to investigate which
+ * consequences this has.
*/(quoted diff) +1
-1-#if 0 // preempt_rt hack, because warn_on in shedule.c triggers +#ifndef CONFIG_PREEMPT_RT #define __ARCH_WANT_INTERRUPTS_ON_CTXSW #endifIt is starting to look like a real fix now, thanks for updating it Thomas .
Quoted 3 lines
Daniel
Sorry, OMAP5910 CPU is ARM 925 (v4).
Thank you, Daniel, it's disapear.
There is stil a bit unclearness for me. When I set config other than PREEMPT_RT this bug occure again.
May be it's ok - if someone want -rt patch on ARM arch, he will want only PREEMPT_RT or I am wrong?
Oleg Kechin.
Quoted 6 lines · Oleg Kechin
Sorry, OMAP5910 CPU is ARM 925 (v4).
Thank you, Daniel, it's disapear.
There is stil a bit unclearness for me. When I set config other thanPREEMPT_RTthis bug occure again.
May be it's ok - if someone want -rt patch on ARM arch, he will want onlyPREEMPT_RTor I am wrong?
My bad. The check in schedule() is there whether PREEMPT_RT is enabled or not. I'm going to look at this.
Thanks,
tglx