Messages in this thread | | | Date | Sun, 18 Jul 2004 02:17:35 +1000 | From | Paul Mackerras <> | Subject | Re: 2.6.7-mm7 |
| |
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?
> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |