Re: Realtime Preemption, 2.6.12, Beginners Guide?

[Alistair John Strachan <s0348365@sms.ed.ac.uk>]

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/