Re: 2.6.7-mm7

From: Andrew Morton (akpm_at_osdl.org)
Date: 07/09/04

  • Next message: Redeeman: "Re: [announce] [patch] Voluntary Kernel Preemption Patch" 
    Date:	Fri, 9 Jul 2004 14:11:03 -0700
To: jhf@rivenstone.net (Joseph Fannin)

    jhf@rivenstone.net (Joseph Fannin) wrote:
    >
    > On Thu, Jul 08, 2004 at 11:50:25PM -0700, Andrew Morton wrote:
    > >
    > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm7/
    >
    > > +detect-too-early-schedule-attempts.patch
    > >
    > > Catch attempts to call the scheduler before it is ready to go.
    >
    > With this patch, my Powermac (ppc32) spews 711 (I think)
    > warning messages during bootup.

    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?

    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
    >
    > and this goes on until:
    >
    > 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
    > [c00062ec] resume_kernel+0x38/0x58
    > [c020249c] schedule+0x304/0x684
    > [c002c85c] worker_thread+0x258/0x27c
    > [c00317d0] kthread+0xb8/0xc0
    > [c0009128] kernel_thread+0x44/0x60
    > adb devices: [2]: 2 2 [3]: 3 1
    > ADB keyboard at 2, handler set to 3
    >
    > The full dmesg is 322K, and is up at:
    > http://www.rivenstone.net/linux/samarkand.dmesg
    >
    > Most of the traces look something like the bottom one.
    >
    > --
    > Joseph Fannin
    > jhf@rivenstone.net
    >
    -
    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/

  • Next message: Redeeman: "Re: [announce] [patch] Voluntary Kernel Preemption Patch"

    Relevant Pages

    • Re: 2.6.7-mm7
      ... warning messages during bootup. ... Badness in schedule at kernel/sched.c:2153 ... Call trace: ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RE: Primary, Secondary, and Tertiary Critical Paths
      ... Consider working the schedule as a backward pass from ... You will trace only tasks with 0 total slack. ... You might consider assigning priorities to the tasks on the critical path. ...
      (microsoft.public.project)
    • 2.6.8-rc1-mm1 "Badness in schedule" on ppc32
      ... >> calls to schedule() occur. ... "Badness in schedule" during boot. ... Call trace: ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch] Latency Tracer, voluntary-preempt-2.6.8-rc4-O6
      ... > Here is a trace showing a latency of 39034us. ... 0.002ms: finish_task_switch (schedule) ... i.e. another CPU is holding the big kernel lock and this CPU is looping. ...
      (Linux-Kernel)
    • Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-R1
      ... One very long trace> 70 msec - this is the third day I've had ... IRQ Sequence ... a> 300 usec time delay. ... see also the "schedule" trace near the end for a similar ...
      (Linux-Kernel)