From owner-freebsd-hackers  Tue Aug 12 21:41:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id VAA20461
          for hackers-outgoing; Tue, 12 Aug 1997 21:41:06 -0700 (PDT)
Received: from implode.root.com (implode.root.com [198.145.90.17])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA20455;
          Tue, 12 Aug 1997 21:41:00 -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 VAA07651;
	Tue, 12 Aug 1997 21:43:13 -0700 (PDT)
Message-Id: <199708130443.VAA07651@implode.root.com>
To: Julian Elischer <julian@FreeBSD.ORG>
cc: hackers@FreeBSD.ORG
Subject: Re: 2.2.2+ crash.. more info 
In-reply-to: Your message of "Tue, 12 Aug 1997 18:10:50 PDT."
             <199708130110.SAA21060@freefall.freebsd.org> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Tue, 12 Aug 1997 21:43:13 -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>it was put onto the sleep queue accidentally by interrupt code
>that just had it's proc address by accident?
>unlikely.

   Quite likely. It's fairly easy to have a bug where a resource is exhausted
(usually memory) in a subroutine called from an interrupt routine, resulting
in a tsleep() if the call to malloc isn't M_NOWAIT. If there happens to be
a process running at the time, then that process will be the one bogusly put
to sleep. This can obviously cause all sorts of problems, not the least of
which is the one you have above. If a process was not running, the system will
usually crash when it dereferences a NULL curproc pointer.
   The fact that the p_wmesg was "swread" is very indicative of this...

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project