KSE/ia64 broken

[Daniel Eischen]

On Sun, 16 Nov 2003, Marcel Moolenaar wrote:

> On Sun, Nov 16, 2003 at 03:09:14PM -0500, Daniel Eischen wrote:
> > On Sun, 16 Nov 2003, Marcel Moolenaar wrote:
> > > On Sun, Nov 16, 2003 at 02:30:20PM -0500, Daniel Eischen wrote:
> > > 
> > > > What should I be looking at, [um]c_flags?
> > > 
> > > mc_flags is very informative.
> > > 
> > > >   $ simple
> > > >   Found completed thread 6000000000014000, uc_flags 0x0, mc_flags 0x8, name initial thread
> > > 
> > > This is a context created by the kernel. It's one created by getcontext().
> > 
> > I'm not sure what you mean by "created by getcontext()".  You
> > mean get_mcontext(), the syscall getcontext(), or userland
> > _ia64_save_context()?  It shouldn't be from the syscall getcontext()
> > because it is the initial thread.
> 
> I meant getcontext(2). _ia64_save_context() always creates contexts
> that have mc_flags=0. Note that all synchronuous contexts created
> by the kernel have valid return registers. It's not only getcontext(2)
> that does that. I was sloppy. The context could be the result of an
> upcall due to a blocking system call.

I think it should be the result of being blocked, probably in
malloc() and sbrk().  When we were using KSE locks for spinlocks,
upcalls were disabled.

> > > Only the kernel needs to preserve the return registers (which is what
> > > mc_flags indicates) because it needs to be able to resume system calls.
> > > 
> > > >   Switching out thread 6000000000014000, state 0
> > > >   Threads in waiting queue:
> > > >   Found completed thread 6000000000014000, uc_flags 0x0, mc_flags 0x3, name initial thread
> > > 
> > > This is an asynchronuous context. Probably the result of a trap, but
> > > possibly the result of an interrupt. Does this mean that the thread
> > > has run since it was last found (i.e. the previous context) or do we
> > > have a case where a context is clobbered (I don't see a switch in)?
> > 
> > Yes, this is the main thread and has run, blocked, and now completed.
> > All three statements above are from the KSE scheduler as a result of
> > an upcall.
> 
> See my comment above.
> 
> > The same thread (main thread) is being resumed over and over again
> > which shouldn't happen for this simple program.
> 
> Can it be that the thread is deadlocked? There's no forward progress.
> There's only context switching...

I don't think so.  I think the thread stack/frame is corrupted, either
because it is copied out or resumed incorrectly.  I'll do some more
digging.

-- 
Dan Eischen