From owner-freebsd-threads@FreeBSD.ORG Sun Nov 16 13:55:46 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1816D16A4CE; Sun, 16 Nov 2003 13:55:46 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AD5143FBD; Sun, 16 Nov 2003 13:55:45 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id hAGLti1G004585; Sun, 16 Nov 2003 16:55:44 -0500 (EST) Date: Sun, 16 Nov 2003 16:55:44 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20031116205616.GB60888@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: davidxu@freebsd.org Subject: Re: KSE/ia64 broken X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2003 21:55:46 -0000 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