On Monday 11 Jul 2005 15:16, Ingo Molnar wrote:
> * Ingo Molnar <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |