KSE/ia64 broken

[Daniel Eischen]

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.

> 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.  The first statement is the scheduler detecting that there
was a thread that was running and that it is no longer running (it's
being switched out).  There are no threads in the waiting queue.
The third statement is from checking the list of unblocked threads
in the KSE mailbox.

The same thread (main thread) is being resumed over and over again
which shouldn't happen for this simple program.

-- 
Dan Eischen