[lkml]   [2005]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Realtime Preemption, 2.6.12, Beginners Guide?
    On Saturday 09 Jul 2005 12:58, Ingo Molnar wrote:
    > * Alistair John Strachan <> wrote:
    > > Got this (slightly better) oops. Figured out how to use my camera :-)
    > >
    > >
    > this was a bit more useful - shows a softirq wakeup. Could you send me
    > your vmlinux (bzip -9 compressed, via private mail), your gcc generates
    > a slightly different code layout so i couldnt match up everything that
    > might be useful.

    Okay, I'll send you the vmlinux from -18 with a new digital photo, and config,
    with CONFIG_4KSTACKS enabled.

    Do you want me to apply the patch blitz you just sent to the list before
    testing? Those are some impressive stack reductions, the
    ip_sockglue.c/blkdev_get() ones in combination look promising.

    > > Onto your stack-footprint metric. I don't know what the number means,
    > > but at a guess it's the size of the stack. Unfortunately, if this is
    > > the case, it's unlikely to be an overflow causing the crash. Here's a
    > > grep of dmesg just before the crash.
    > it could still be near an overflow. To make sure i've changed the oops
    > printout to also include the current stack left, and the worst-case
    > stack-left value, and have uploaded the -51-18 kernel - could you try
    > it? That way we can tell for sure. (note that the maximum-tracker can
    > not always do an immediate printout of a worst-case - we have to skip
    > printouts if irqs are disabled. [or we could recurse from within the
    > scheduler or the printk code] Even in those cases we save the worst-case
    > stack and print it out as soon as interrupts are enabled again. (The
    > worst-case stack-left value printed out at oops time is immediate.)

    I guess also, as you suggested elsewhere in this thread, I could try an 8K
    stacks kernel, let openvpn run (even just for 5 minutes, then close it) and
    see if I get a stack-footprint dump *for openvpn*, which so far I've not been
    able to observe.

    Hopefully this would negate the possibility that there's a stack-footprint
    waiting to be generated, but just masked by the crash.

    Is this actually useful to you?


    personal: alistair()devzero!co!uk
    university: s0348365()sms!ed!ac!uk
    student: CS/CSim Undergraduate
    contact: 1F2 55 South Clerk Street,
    Edinburgh. EH8 9PP.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-07-09 16:10    [W:0.041 / U:1.024 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site