Re: Realtime Preemption, 2.6.12, Beginners Guide?

From: Alistair John Strachan (s0348365_at_sms.ed.ac.uk)
Date: 07/11/05

  • Next message: Hal Rosenstock: "[PATCH 16/27] Add ib_create_ah_from_wc to IB verbs" 
    To: Ingo Molnar <mingo@elte.hu>
Date:	Mon, 11 Jul 2005 15:38:22 +0100

    On Monday 11 Jul 2005 15:16, Ingo Molnar wrote:
    > * Ingo Molnar <mingo@elte.hu> wrote:
    > > might be an incorrect printout of stack_left :( The esp looks more or
    > > less normal. Not sure why it printed -52.
    >
    > here's the stack_left calculation:
    >
    > + printk("ds: %04x es: %04x ss: %04x preempt: %08x\n",
    > + regs->xds & 0xffff, regs->xes & 0xffff, ss,
    > preempt_count()); + printk("Process %s (pid: %d, threadinfo=%p
    > task=%p stack_left=%ld worst_left=%ld)", + current->comm,
    > current->pid, current_thread_info(), current, + (regs->esp &
    > (THREAD_SIZE-1))-sizeof(struct thread_info), +
    > worst_stack_left);
    >
    > i cannot see anything wrong in it, but your esp is 0xc04cded0,
    > THREAD_SIZE-1 is 0xfff, so the result should be:
    >
    > 0xed0-sizeof(struct thread_info).
    >
    > which should not be -52.

    Actually, it's now pretty much confirmed that this ISN'T a stack overflow, not
    just because of what you've said (now and before), but also because I've
    tried an 8K stacks kernel and, sadly, there's no stand-out stack abusers.

    It's annoying that this is so readily reproducible here, yet almost impossible
    to debug, and clearly a sideaffect of 4KSTACKS.. without it actually being a
    stack overflow.

    I realise 4KSTACKS is a considerable rework of the IRQ handler, etc. and
    probably even more heavily modified by rt-preempt, but is there nothing else
    that can be tested before a serial console run? 

    -- 
Cheers,
Alistair.
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 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: Hal Rosenstock: "[PATCH 16/27] Add ib_create_ah_from_wc to IB verbs"

    Relevant Pages

    • Re: Realtime Preemption, 2.6.12, Beginners Guide?
      ... and clearly a sideaffect of 4KSTACKS.. ... > actually being a stack overflow. ... > I realise 4KSTACKS is a considerable rework of the IRQ handler, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: How to find out kernel stack over flow?
      ... >>the kernel may be causing the stack overflow which is ... Nominally a stack overflow results in the corruption of data at the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: kernel OOPS for XFS in xfs_iget_core (using NFS+SMP+MD)
      ... Couldn't this be a stack overflow? ... That's a very large kernel stack. ... Lee ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.4.30-hf1 do_IRQ stack overflows
      ... Do you have the "do_IRQ stack overflow" output and the amount of bytes ... I dont see any huge stack consumers on this callchain. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)