From owner-freebsd-hackers Tue Sep 23 22:45:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA02992 for hackers-outgoing; Tue, 23 Sep 1997 22:45:43 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA02987 for ; Tue, 23 Sep 1997 22:45:40 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id WAA20450; Tue, 23 Sep 1997 22:47:53 -0700 (PDT) Message-Id: <199709240547.WAA20450@implode.root.com> To: Archie Cobbs cc: freebsd-hackers@FreeBSD.ORG Subject: Re: is this a bug? In-reply-to: Your message of "Tue, 23 Sep 1997 19:08:53 PDT." <199709240208.TAA04263@bubba.whistle.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 23 Sep 1997 22:47:53 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >We're trying to track down a very elusive bug that involves processes >ending up on two queues at once, or having runnable state SRUN and >being on a sleep queue, ... etc.. > >Question: is there a bug in this code from tsleep() ? The code does this: > > 1. Puts process on a sleep queue > 2. Calls CURSIG(), which can result in a context switch > 3. Sets p->p_stat to SSLEEP > >It seems steps #2 and #3 are out of order... couldn't this result >in a process being on a sleep queue yet having state SRUN? After a quick look at this, the code does look like it could contain some bugs, although I don't yet see a path that could explain the panic. There are a couple possible causes of something like this...one of them is a driver or kernel routine calling tsleep() while in an interrupt routine (a no no), perhaps due to a malloc with M_WAITOK - this is the most common cause. There might also be some hidden recursion in tsleep or children of it that could cause this; I don't see that in the code, however. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project