From owner-freebsd-mobile  Wed Oct 29 07:16:15 1997
Return-Path: <owner-freebsd-mobile>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA21001
          for mobile-outgoing; Wed, 29 Oct 1997 07:16:15 -0800 (PST)
          (envelope-from owner-freebsd-mobile)
Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA20996
          for <freebsd-mobile@freebsd.org>; Wed, 29 Oct 1997 07:16:12 -0800 (PST)
          (envelope-from nate@rocky.mt.sri.com)
Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id IAA01624;
	Wed, 29 Oct 1997 08:16:09 -0700 (MST)
Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id IAA11236; Wed, 29 Oct 1997 08:16:06 -0700 (MST)
Date: Wed, 29 Oct 1997 08:16:06 -0700 (MST)
Message-Id: <199710291516.IAA11236@rocky.mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Brian N. Handy" <handy@sag.space.lockheed.com>
Cc: Satoshi Asami <asami@cs.berkeley.edu>, freebsd-mobile@freebsd.org,
        Nate Williams <nate@sri.MT.net>
Subject: Re: Real hackers run -current
In-Reply-To: <Pine.OSF.3.96.971028222020.17778A-100000@sag.space.lockheed.com>
References: <199710290408.UAA12369@silvia.HIP.Berkeley.EDU>
	<Pine.OSF.3.96.971028222020.17778A-100000@sag.space.lockheed.com>
X-Mailer: VM 6.29 under 19.15 XEmacs Lucid
Sender: owner-freebsd-mobile@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> have scored one hang -- I had my modem and enet card in, and popped them
> out simultaneously.  This wedged the system pretty well!  (Not sure if it
> was the combimation of the two, or if my ethernet card was in a wierd
> state.)

I'm pretty sure this is a 'known race' that can't be worked around.
Simply put, if you yank the cards out from under the system, there is a
chance that you can't hang your system if the kernel is talking to the
hardware at this point, and it's waiting for a result.  The only
solution to this is to write drivers that are *very* paranoid about the
results, but these tend to be slower since sanity checks are done on
everything, so that's not necessarily a good solution either.

In any case, I'm not *really* concerned abou this sort of thing, since I
can hang my Win95 box this way as well. :)



Nate