Re: 2.6.7-mm7

[Joseph Fannin]

On Sun, Jul 18, 2004 at 02:17:35AM +1000, Paul Mackerras wrote:
> Andrew Morton writes:
> 
> > hm, OK.  It could be that the debug patch is a bit too aggressive, or that
> > ppc got lucky and happens to always be in state TASK_RUNNING when these
> > calls to schedule() occur.
> > 
> > Maybe this task incorrectly has _TIF_NEED_RESCHED set?
> 
> Is CONFIG_PREEMPT enabled?

    These traces are with preempt enabled, but I tried turning it off
and the messages are still there (there seem to be a lot less of them,
though.)

    I would be glad to produce a dmesg with preempt off if it makes
things clearer (tonight, or tommorrow, or I'd just do it now.)
 
> > Anyway, ppc guys: please take a look at the results from
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm7/broken-out/detect-too-early-schedule-attempts.patch
> > and check that the kernel really should be calling schedule() at this time
> > and place, let us know?
> > 
> > Thanks.
> > 
> > >  The first one looks like:
> > >
> > > Calibrating delay loop... 1064.96 BogoMIPS
> > > Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> > > Badness in schedule at kernel/sched.c:2153
> > > Call trace:
> > >  [c00099e4] dump_stack+0x18/0x28
> > >  [c0006bac] check_bug_trap+0x84/0xac
> > >  [c0006d38] ProgramCheckException+0x164/0x1a4
> > >  [c0006240] ret_from_except_full+0x0/0x4c
> > >  [c02021bc] schedule+0x24/0x684
> > >  [c0005e80] syscall_exit_work+0x108/0x10c
> > >  [c02e0ad0] proc_root_init+0x14c/0x158
> > >  [00000000] 0x0
> > >  [c02ce5a0] start_kernel+0x158/0x184
> > >  [000035fc] 0x35fc
> 
> This looks like CONFIG_PREEMPT is enabled and _TIF_NEED_RESCHED is set
> at the end of handling a system call.  AFAICS i386 will also call
> schedule in these circumstances.  Does this mean we shouldn't do
> system calls until the scheduler is running?
> 
> Paul.
> 

-- 
Joseph Fannin
jhf@xxxxxxxxxxxxxx

Attachment: signature.asc
Description: Digital signature