From owner-freebsd-threads@FreeBSD.ORG Sun Jul 4 20:58:29 2004 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 886BD16A4CE for ; Sun, 4 Jul 2004 20:58:29 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3556343D1D for ; Sun, 4 Jul 2004 20:58:27 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i64Kw5qM011265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jul 2004 16:58:05 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i64KvwQv014978; Sun, 4 Jul 2004 16:57:58 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16616.28502.692389.458282@grasshopper.cs.duke.edu> Date: Sun, 4 Jul 2004 16:57:58 -0400 (EDT) To: Julian Elischer In-Reply-To: References: <16613.53106.413179.808734@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-threads@freebsd.org cc: Andrew Gallatin Subject: Re: odd KSE panic 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, 04 Jul 2004 20:58:29 -0000 Julian Elischer writes: > When one thread calls exit() it marks the fact that the process is > exiting, and then tries to wakeup all the other threads, and then > suspends itself. The other threads, when awoken are supposed to notice > what's going on and abort whatever they are doing and when they release > all their resources, (by unrolling back to the user boundary) they are > supposed to call thread_exit(). The last one out is supposed to > wakeyup the original thread that called exit(), which can then proceed > on the basis that it is now the only remaining thread. > > If there are threads waiting in uninterruptble sleeps then the process > as a whole can not exit until they have finished sleeping and come back > to the user boundary and called thread_exit(). > > None of the three threads you show is in exit, or even anything related > to exit. > Thank you for this explaination.. The way that threads exit is one of the things I've never understood about KSE. > > ummmm nope.. where is mx_free? > Unreleased 3rd party device driver.. Drew