From owner-freebsd-threads@FreeBSD.ORG Sun Nov 16 11:53:44 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 4564F16A4CE; Sun, 16 Nov 2003 11:53:44 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A11243F3F; Sun, 16 Nov 2003 11:53:43 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id hAGJrgbe051893; Sun, 16 Nov 2003 11:53:42 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) hAGJrgbH060809; Sun, 16 Nov 2003 11:53:42 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id hAGJrgen060808; Sun, 16 Nov 2003 11:53:42 -0800 (PST) (envelope-from marcel) Date: Sun, 16 Nov 2003 11:53:42 -0800 From: Marcel Moolenaar To: Daniel Eischen Message-ID: <20031116195342.GA60773@dhcp01.pn.xcllnt.net> References: <20031116182219.GB60377@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i 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 19:53:44 -0000 On Sun, Nov 16, 2003 at 02:30:20PM -0500, Daniel Eischen wrote: > On Sun, 16 Nov 2003, Marcel Moolenaar wrote: > > > On Sun, Nov 16, 2003 at 12:18:33PM -0500, Daniel Eischen wrote: > > > > > > Are you sure there's not an ia64 kernel bug or ia64 context > > > restoring bug? > > > > There's nothing pointing in that direction yet. I keep thinking > > that the case is related to having TP per thread on ia64, while > > it's per KSE on i386. > > If you noop the spinlock/spinunlock, the problem still > occurs. Hmmm, good to know. It tells me that the lock is in reality already a no-op :-) > 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(). 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)? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net