Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

kern/120786: Kernelpanik when forced umount of a dettached USB

2 views
Skip to first unread message

Gerhard Schmidt

unread,
Feb 18, 2008, 4:41:52 AM2/18/08
to

>Number: 120786
>Category: kern
>Synopsis: Kernelpanik when forced umount of a dettached USB Harddisk
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Feb 18 09:40:00 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Gerhard Schmidt
>Release: FreeBSD 6-STABLE.
>Organization:
Technische Universität münchen
>Environment:
FreeBSD etustar.ze.tum.de 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #2: Mon Nov 12 09:02:05 CET 2007 ro...@etustar.ze.tum.de:/usr/src/sys/i386/compile/ETUSTAR i386
>Description:
I have an USB Harddisk mounted. It gets detached without propper umount.

umount the filesystem fails due to a readerror (expected)

when i try a umount -f freebsd panics.

The same error in FreeBSD 7
>How-To-Repeat:
mount an USB Harddisk
diskconnect the Harddisk without umount
umount -f the filesystem -> Crash
>Fix:
n/k

>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs...@freebsd.org"

Bruce Evans

unread,
Feb 18, 2008, 12:18:11 PM2/18/08
to
On Mon, 18 Feb 2008 ga...@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

0 new messages