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

[Joel Sherrill]

Mike Panetta wrote:
> 
> 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!

Just a guess but if you are downloading using bdm, there could be some
timing problem created by heavy swapping.  This might corrupt the image
going down.  Just a guess.

This is why I prefer simulators whenever possible.  Real hardware
can be such a pain. :)

> 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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985