WARN_ON noise in 2.5.63's kernel/sched.c:context_switch

WARN_ON noise in 2.5.63's kernel/sched.c:context_switch

[Miles Bader]

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

Re: WARN_ON noise in 2.5.63's kernel/sched.c:context_switch

[William Lee Irwin III]

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

Re: WARN_ON noise in 2.5.63's kernel/sched.c:context_switch

[Miles Bader]

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

Re: WARN_ON noise in 2.5.63's kernel/sched.c:context_switch

[William Lee Irwin III]

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