* WARN_ON noise in 2.5.63's kernel/sched.c:context_switch
@ 2003-02-25 6:35 Miles Bader
2003-02-25 6:37 ` William Lee Irwin III
0 siblings, 1 reply; 4+ messages in thread
From: Miles Bader @ 2003-02-25 6:35 UTC (permalink / raw)
To: linux-kernel
I'm getting a bunch of stack dumps from the WARN_ON newly added to
kernel/sched.c:context_switch:
if (unlikely(!prev->mm)) {
prev->active_mm = NULL;
WARN_ON(rq->prev_mm);
rq->prev_mm = oldmm;
}
The thing is, I'm hacking on uClinux, so I don't have an MMU, and the mm
stuff is purely noise. What's the best way to squash this warning?
[Of course I'd like to just trash all the MM manipulation -- for me,
`context_switch' should really _just_ do `switch_to' -- but I'd settle
for just not having stack dumps litter my console output...]
Thanks,
-miles
--
80% of success is just showing up. --Woody Allen
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: WARN_ON noise in 2.5.63's kernel/sched.c:context_switch
2003-02-25 6:35 WARN_ON noise in 2.5.63's kernel/sched.c:context_switch Miles Bader
@ 2003-02-25 6:37 ` William Lee Irwin III
2003-03-05 7:13 ` Miles Bader
0 siblings, 1 reply; 4+ messages in thread
From: William Lee Irwin III @ 2003-02-25 6:37 UTC (permalink / raw)
To: Miles Bader; +Cc: linux-kernel
On Tue, Feb 25, 2003 at 03:35:22PM +0900, Miles Bader wrote:
> I'm getting a bunch of stack dumps from the WARN_ON newly added to
> kernel/sched.c:context_switch:
> if (unlikely(!prev->mm)) {
> prev->active_mm = NULL;
> WARN_ON(rq->prev_mm);
> rq->prev_mm = oldmm;
> }
> The thing is, I'm hacking on uClinux, so I don't have an MMU, and the mm
> stuff is purely noise. What's the best way to squash this warning?
> [Of course I'd like to just trash all the MM manipulation -- for me,
> `context_switch' should really _just_ do `switch_to' -- but I'd settle
> for just not having stack dumps litter my console output...]
This means there's some kind of trouble happening, i.e. the rq->prev_mm
pointer is not NULL when it should be.
Tracking down the root cause would better serve you.
-- wli
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: WARN_ON noise in 2.5.63's kernel/sched.c:context_switch
2003-02-25 6:37 ` William Lee Irwin III
@ 2003-03-05 7:13 ` Miles Bader
2003-03-05 7:24 ` William Lee Irwin III
0 siblings, 1 reply; 4+ messages in thread
From: Miles Bader @ 2003-03-05 7:13 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: linux-kernel
William Lee Irwin III <wli@holomorphy.com> writes:
> On Tue, Feb 25, 2003 at 03:35:22PM +0900, Miles Bader wrote:
> > I'm getting a bunch of stack dumps from the WARN_ON newly added to
> > kernel/sched.c:context_switch:
> > if (unlikely(!prev->mm)) {
> > prev->active_mm = NULL;
> > WARN_ON(rq->prev_mm);
> > rq->prev_mm = oldmm;
> > }
>
> This means there's some kind of trouble happening, i.e. the rq->prev_mm
> pointer is not NULL when it should be.
>
> Tracking down the root cause would better serve you.
Ok, I think I found the reason; sched.c cleans up some stuff in
schedule_tail, and in this code (arch/v850/kernel/entry.S):
C_ENTRY(ret_from_fork):
#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
mov r10, r6 // switch_thread returns the prev task.
jarl CSYM(schedule_tail), lp // ...which is schedule_tail's arg
#endif
mov r0, r10 // Child's fork call should return 0.
br ret_from_trap // Do normal trap return.
... it only calls that if CONFIG_PREEMPT is turned on. If I remove the
#ifdef, then I get no warnings.
I take it that the call to schedule_tail should now be unconditional?
[some other archs have the same #ifdef]
Thanks,
-Miles
--
97% of everything is grunge
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: WARN_ON noise in 2.5.63's kernel/sched.c:context_switch
2003-03-05 7:13 ` Miles Bader
@ 2003-03-05 7:24 ` William Lee Irwin III
0 siblings, 0 replies; 4+ messages in thread
From: William Lee Irwin III @ 2003-03-05 7:24 UTC (permalink / raw)
To: Miles Bader; +Cc: linux-kernel
On Wed, Mar 05, 2003 at 04:13:48PM +0900, Miles Bader wrote:
> Ok, I think I found the reason; sched.c cleans up some stuff in
> schedule_tail, and in this code (arch/v850/kernel/entry.S):
> C_ENTRY(ret_from_fork):
> #if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
> mov r10, r6 // switch_thread returns the prev task.
> jarl CSYM(schedule_tail), lp // ...which is schedule_tail's arg
> #endif
> mov r0, r10 // Child's fork call should return 0.
> br ret_from_trap // Do normal trap return.
> ... it only calls that if CONFIG_PREEMPT is turned on. If I remove the
> #ifdef, then I get no warnings.
> I take it that the call to schedule_tail should now be unconditional?
> [some other archs have the same #ifdef]
Yeah, this is the root problem. You have to go through schedule_tail()
to clean up the mm's etc.
-- wli
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-03-05 7:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-25 6:35 WARN_ON noise in 2.5.63's kernel/sched.c:context_switch Miles Bader
2003-02-25 6:37 ` William Lee Irwin III
2003-03-05 7:13 ` Miles Bader
2003-03-05 7:24 ` William Lee Irwin III
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).