Its fixed... (was: Stack corruption problem?)

[Mike Panetta]

Ok...  I have fixed it.  I do not know how.  I undid the last thing I
changed, and its still fixed.  The only big change that I did, was quit
out of mozilla, which was using over half my ram (I am on a laptop with
128MB ram), causing the build process to swap heavly, and then I did a
full reconfig/compile.  If this is really what fixed the problem (IE it
was really some sort of Linux kernel bug), I am sorry for bothering you
guys so much.  Either way, the good news is now it seems to work.  So
far I have run base_sp, and ticker successfully without any other
incident other then the CPU32BUG being hosed after the program exits
(understandable since I muck with the SPI registers it depends on).  Now
that I think about it, the last time I remember it working (with the
hello sample) was when I did not have mozilla running... Maybe there is
a trend... If so, I think I should upgrade my kernel!


Mike


On Thu, 2002-02-28 at 11:40, Chris Johns wrote:
> Mike Panetta wrote:
> > 
> > Well maybe,  I donno yet.  I do know that I was confused about where the
> > stack should have been after the process starts.  Its intresting what
> > you can learn after stepping through a context switch in a debugger :).
> > Apparently the stack for processes is allocated in an area at the end of
> > memory called the workspace.  So the SP being above the stack top is
> > normal if your in a process.
> > 
> 
> You are correct, task stacks are allocated from the workspace. The RTEMS
> interrupt handler on all m68k's will perform a stack switch. That is
> interrupts are handled on an interrupt stack. This save the overhead of
> each task needing to allocate the worst case interrupt stack usage. The
> interrupt stack size can be configured; I think the configuration table.
> It should default to something like 4096 bytes which should be more than
> enough for most applications.
> 
> > 
> > I donno.  I cant figure it out in GDB, because the code acts different
> > in the debugger :(
> > 
> 
> RTEMS only uses the supervisor mode.
> 
> -- 
>  Chris Johns, cjohns at cybertec.com.au