From owner-freebsd-current@FreeBSD.ORG Wed May 21 00:57:10 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D31FC37B401 for ; Wed, 21 May 2003 00:57:10 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3360F43FB1 for ; Wed, 21 May 2003 00:57:10 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h4L7v9qN004916; Wed, 21 May 2003 00:57:09 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h4L7v97b004915; Wed, 21 May 2003 00:57:09 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 21 May 2003 00:57:09 -0700 From: David Schultz To: Bruce Evans Message-ID: <20030521075709.GB4783@HAL9000.homeunix.com> Mail-Followup-To: Bruce Evans , Jun Kuriyama , Current References: <7m4r3onc7i.wl@black.imgsrc.co.jp> <20030521163526.I30051@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030521163526.I30051@gamplex.bde.org> cc: Jun Kuriyama cc: Current Subject: Re: panic: mount: lost mount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 07:57:11 -0000 On Wed, May 21, 2003, Bruce Evans wrote: > On Wed, 21 May 2003, Jun Kuriyama wrote: > > > With today's current, I've got a panic with bad floppy. > > > > fd0: hard error cmd=read fsbn 57 of 56-63 (ST0 44 ST1 20 ST2 20 cyl 1 hd 1 sec 4) > > panic: mount: lost mount > > cpuid = 1; lapic.id = 01000000 > > Debugger("panic") > > Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 > > db> trace > > Debugger(c03eb40e,1000000,c03f085e,ebc05b80,1) at Debugger+0x55 > > panic(c03f085e,ebc05ba4,c03f0812,46a,c896b720) at panic+0x11f > > vfs_mount(c896b720,c7eafd40,c8a32b80,0,bfbfece0) at vfs_mount+0xa80 > > mount(c896b720,ebc05d10,c0407bf6,3fb,4) at mount+0xb8 > > syscall(2f,2f,2f,80a210f,bfbff6a4) at syscall+0x26e > > Xint0x80_syscall() at Xint0x80_syscall+0x1d > > Unfortunately, this is fairly normal file system behaviour when a critical > block is unreadable or damaged. Here vfs detects a problem that it knows > it cannot handle, and panics. I've run into this as well while testing other properties of how removable media is handled. Is there an easy way to get slightly more graceful behavior, such as forcing a downgrade to r/o and zapping the vnodes for any unrecoverable files a la 'umount -f'?