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>