From owner-freebsd-bugs@FreeBSD.ORG Sat Apr 1 21:49:04 2006 Return-Path: X-Original-To: freebsd-bugs@freebsd.org Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23EC016A400 for ; Sat, 1 Apr 2006 21:49:04 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6352043D5E for ; Sat, 1 Apr 2006 21:49:03 +0000 (GMT) (envelope-from jason.harmening@gmail.com) Received: by zproxy.gmail.com with SMTP id l8so1190720nzf for ; Sat, 01 Apr 2006 13:49:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=YnKAq+uk0wk6P/fedVzl8BAI0ghX96uGs+ZJbjGZUDaXPmGdrCJYBxvSipTa22pjNao1XtxZUE15WlnV3BXm4EvIjHdCDzCvF0yJc++yOXc0nw6Yo/5GTfwzzAzn0W9Mlemy//2QApjqaG5YwyaaKDaE7EacHVTiRHjcuDuWxC8= Received: by 10.37.20.57 with SMTP id x57mr443831nzi; Sat, 01 Apr 2006 13:49:02 -0800 (PST) Received: from ?192.168.0.3? ( [70.112.20.140]) by mx.gmail.com with ESMTP id 23sm966323nzn.2006.04.01.13.49.02; Sat, 01 Apr 2006 13:49:02 -0800 (PST) From: Jason Harmening To: Kris Kennaway Date: Sat, 1 Apr 2006 15:45:11 -0600 User-Agent: KMail/1.9.1 References: <2d1264630603161045t31774a33h9cec88c4b7d6d13d@mail.gmail.com> <200603181929.25821.jason.harmening@gmail.com> <20060319013927.GA65792@xor.obsecurity.org> In-Reply-To: <20060319013927.GA65792@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604011545.11455.jason.harmening@gmail.com> Cc: freebsd-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [6.1-PRERELEASE/amd64] Kernel panic during heavy UFS traffic X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2006 21:49:04 -0000 On Saturday 18 March 2006 19:39, you wrote: > On Sat, Mar 18, 2006 at 07:29:25PM -0600, Jason Harmening wrote: > > I finally managed to reproduce the mount panic on the console: > > > > CORONA% mount /dev/acd0 /home/jason/dvdram > > g_vfs_done():acd0[READ(offset=114688, length=16384)]error = 5 > > panic: mount: lost mount > > cpuid = 0 > > KDB: stack backtrace: > > kdb_backtrace() at kdb_backtrace+0x37 > > panic() at panic+0x1d1 > > vfs_domount() at vfs_domount+0x9ae > > vfs_donmount() at vfs_donmount+0x400 > > kernel_mount() at kernel_mount+0x40 > > ffs_cmount() at ffs_cmount+0x7c > > mount() at mount+0x1e3 > > syscall() at syscall+0x3a4 > > Xfast_syscall() at Xfast_syscall+0xa8 > > --- syscall (21, FreeBSD ELF64, mount), rip = 0x80067e0dc, rsp = > > 0x7fffffffdc88, rbp = 0x7 > > fffffffe748 --- > > Uptime: 1m34s > > Dumping 1023 MB (2 chunks) > > > > I'm starting to worry this may be a hardware issue... > > Yes, it could well be (or bad media) - the drive returned an I/O error > (error 5 = EIO) when you tried to mount the media. > > > If it is, would there be > > a more elegant way for the OS to handle a failed removable drive mount > > besides panicking? > > In principle, yes. I don't know if there's any hope of getting it > fixed in time for 6.1, but please file a PR with this trace. I filed PR 94669 for this issue and finally took some time to do some further investigation on my own. I've found the following: 1. I can invariably mount the DVD-RAM successfully if I first do some operation on the disk that doesn't require it to be mounted (namely, an fsck), or if I've previously mounted successfully and haven't since ejected the media. I will only see the panic if I try to mount immediately after inserting the media, and then not 100% of the time. This leads me to believe there may be some confusion between the drive, the ATAPI CD/DVD driver, and the VFS subsystem as to when, exactly, the drive is ready for mounting. 2. I looked at the VFS sources for RELENG_6 and found the point at which the panic seems to be occurring--lines 891-892 of vfs_mount.c: if (VFS_ROOT(mp, LK_EXCLUSIVE, &newdp, td)) panic("mount: lost mount"); So essentially the invocation of mp->mount_op->vfs_root (In this case, I'm guessing whatever the vfs_root function for UFS is) returns an error. Would it be safe to handle this error by returning an error code instead of panicking? Or would this have undesirable ramifications for auto-mounted filesystems on fixed disks, or could the failed vfs_root possibly induce side-effects that would leave the kernel in an unstable state? I don't know much about the FreeBSD VFS, but I'm willing to take a crack at fixing/testing this. Thanks, Jason > > Kris