Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Nov 2003 12:56:16 -0800
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Daniel Eischen <eischen@vigrid.com>
Cc:        davidxu@freebsd.org
Subject:   Re: KSE/ia64 broken
Message-ID:  <20031116205616.GB60888@dhcp01.pn.xcllnt.net>
In-Reply-To: <Pine.GSO.4.10.10311161457520.9596-100000@pcnet5.pcnet.com>
References:  <20031116195342.GA60773@dhcp01.pn.xcllnt.net> <Pine.GSO.4.10.10311161457520.9596-100000@pcnet5.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> > 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...

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031116205616.GB60888>