From owner-freebsd-bugs@FreeBSD.ORG Wed Nov 29 22:00:41 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D26016A4CE for ; Wed, 29 Nov 2006 22:00:41 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16F4643CB6 for ; Wed, 29 Nov 2006 22:00:32 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kATM0alp077026 for ; Wed, 29 Nov 2006 22:00:36 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kATM0aaa077025; Wed, 29 Nov 2006 22:00:36 GMT (envelope-from gnats) Date: Wed, 29 Nov 2006 22:00:36 GMT Message-Id: <200611292200.kATM0aaa077025@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Robert Watson Cc: 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: Robert Watson List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2006 22:00:41 -0000 The following reply was made to PR kern/106030; it has been noted by GNATS. From: Robert Watson To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/106030: panic while rebooting with a dead disk Date: Wed, 29 Nov 2006 21:51:32 +0000 (GMT) On Wed, 29 Nov 2006, Charlie & wrote: >> Description: > > I had a mounted ufs disk that went away. I rebooted so as to avoid a panic. > Too bad. Geom paniced on me anyway: > > Syncing disks, vnodes remaining...2 (da8:isp1:0:6:2): Invalidating pack > g_vfs_done():da8a[WRITE(offset=81920, length=4096)]error = 6 > panic: bundirty: buffer 0xc6d76f70 still on queue 1 > cpuid = 0 > KDB: enter: panic > [thread pid 3 tid 100000 ] > Stopped at kdb_enter+0x2b: nop > db> bt > Tracing pid 3 tid 100000 td 0xc1e98000 > kdb_enter(c0936604) at kdb_enter+0x2b > panic(c093f33c,c6d76f70,1,c6d76f70,cba0ec48,...) at panic+0x127 > bundirty(c6d76f70) at bundirty+0x35 > brelse(c6d76f70) at brelse+0x82f > bufdone_finish(c6d76f70) at bufdone_finish+0x34c > bufdone(c6d76f70) at bufdone+0xaa > ffs_backgroundwritedone(c6d76f70) at ffs_backgroundwritedone+0xca > bufdone(c6d76f70) at bufdone+0x8f > g_vfs_done(c21475ac) at g_vfs_done+0x8a > biodone(c21475ac) at biodone+0x58 > g_io_schedule_up(c1e98000) at g_io_schedule_up+0xe6 > g_up_procbody(0,cba0ed38) at g_up_procbody+0x5a > fork_exit(c067d58c,0,cba0ed38) at fork_exit+0xac > 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? Robert N M Watson Computer Laboratory University of Cambridge