From owner-freebsd-bugs@FreeBSD.ORG Wed Nov 29 22:17:26 2006 Return-Path: X-Original-To: freebsd-bugs@freebsd.org Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36F9816A49E; Wed, 29 Nov 2006 22:17:26 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEB0143C9D; Wed, 29 Nov 2006 22:17:21 +0000 (GMT) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id kATMHFhh026770; Wed, 29 Nov 2006 14:17:25 -0800 (PST) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id kATMHFxm026767; Wed, 29 Nov 2006 14:17:15 -0800 (PST) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Wed, 29 Nov 2006 14:17:15 -0800 (PST) From: mjacob@freebsd.org X-X-Sender: mjacob@ns1.feral.com To: Robert Watson In-Reply-To: <200611292200.kATM0aaa077025@freefall.freebsd.org> Message-ID: <20061129141647.C26764@ns1.feral.com> References: <200611292200.kATM0aaa077025@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@freebsd.org Subject: Re: kern/106030: panic while rebooting with a dead disk X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2006 22:17:26 -0000 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip = 0, esp = 0xcba0ed6c, ebp = 0 --- > > > > It's unclear to me where this should be fixed. Since device invalidation is > > an inherently asynchronous process that could happen at any time, it seems > > to me that GEOM should be a bit more tolerant here. > > That looks a lot like a UFS/buffer cache panic, not a GEOM panic? Good point.