From owner-freebsd-bugs@FreeBSD.ORG Mon Feb 18 17:16:45 2008 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75A4716A419 for ; Mon, 18 Feb 2008 17:16:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id F390E13C442 for ; Mon, 18 Feb 2008 17:16:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1IHGZIn007366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 04:16:37 +1100 Date: Tue, 19 Feb 2008 04:16:34 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: gavin@freebsd.org In-Reply-To: <200802181431.m1IEVIvO063079@freefall.freebsd.org> Message-ID: <20080219040611.U10725@besplex.bde.org> References: <200802181431.m1IEVIvO063079@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@freebsd.org, schmidt@ze.tum.de Subject: Re: kern/120786: Kernelpanik when forced umount of a dettached USB Harddisk 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: Mon, 18 Feb 2008 17:16:45 -0000 On Mon, 18 Feb 2008 gavin@freebsd.org wrote: > Synopsis: Kernelpanik when forced umount of a dettached USB Harddisk > > State-Changed-From-To: open->closed > State-Changed-By: gavin > State-Changed-When: Mon Feb 18 14:30:37 UTC 2008 > State-Changed-Why: > Close, duplicate of usb/46176 Not quite the same. 46176 mentions the file system, which is the immediate cause of the panic. I fixed the file system (msdosfs) in -current a while ago, and I think the fix is in RELENG_7 but not RELENG_6. Forcing the unmount is not supported, but msdosfs sort of did it anyway, in a bad way that guaranteed a panic near the end of the forced unmount. Now the forced unmount fails instead of panicing. The file system still keeps retrying writes forever, so it may clobber new media, or it may be confused mixing data from new and old media. Corruption from the former, and the latter, may cause a panic eventually. Bruce