From owner-freebsd-threads@FreeBSD.ORG Fri Jul 2 19:36:25 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 0A70116A4CE for ; Fri, 2 Jul 2004 19:36:25 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DB6C43D1F for ; Fri, 2 Jul 2004 19:36:24 +0000 (GMT) (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 i62JYu3u004748; Fri, 2 Jul 2004 15:34:56 -0400 (EDT) Date: Fri, 2 Jul 2004 15:34:56 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Andrew Gallatin In-Reply-To: <16613.45444.528419.643022@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org 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: Fri, 02 Jul 2004 19:36:25 -0000 On Fri, 2 Jul 2004, Andrew Gallatin wrote: > > I've got a character device which is used for OS-bypass NIC, and I've > got a problem.. > > We just started using a second thread in our userland library. The > idea is this worker thread ioctls into the driver, where he sleeps > waiting for an interrupt from the NIC. When he gets the interrupt, > he wakes up and returns from the ioctl, where he will process some > recently completed events. > > The problem happens when exiting. When main application thread > decides to exit, it does an ioctl into the driver to wakeup the > sleeping worker thread. The worker thread thread wakes up, and then > exits, then the main thread closes his file descriptor and exits. > > The problem I'm seeing is that I get a panic like the following when > using KSE. (A linux binary works fine, ioctls are translated..) > > The interesting thing is that there is no stack.. Just one function > from my driver (mx_free()) sitting out there by itself. Is the kernel > somehow ripping the kernel stacks of all threads out from under them > when one thread calls exit()? How do I take a reference so I > don't risk getting marooned without a stack? exit() exits the process, including reaping all kernel threads. I'm not sure why one thread (worker) doing an exit() will still allow other threads to continue running. You should be using pthread_exit() to exit from the worker thread, but that still doesn't explain why you're having the problem. I think just calling exit() in the application is sufficient also. There's no need to GC the worker thread since the kernel should take care of all the other threads. -- Dan Eischen