misc/108199: System crash while trying to unmount manually ejected
USB Flash drive
ggg_mail at inbox.ru
Mon Jan 22 03:00:35 UTC 2007
>Synopsis: System crash while trying to unmount manually ejected USB Flash drive
>Arrival-Date: Mon Jan 22 03:00:34 GMT 2007
>Originator: Rechistov Grigory
FreeBSD ipv82-180.rt.private.mipt.ru 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sat Jan 13 21:02:10 MSK 2007 GGG at ipv82-180.rt.private.mipt.ru:/usr/obj/usr/src/sys/DELL_v3 i386
System reboots, often without displaying a panic message, sometimes producing "page fault while in kernel mode", when trying to execute "umount -f /dev/da0s1"
if mounted flash drive was physically removed from USB port. When trying "umount /dev/da0s1" without -f flag, an error
"Device not configured" appears, and nothing happens, e.g. system thinks that smth is still mounted as da0s1.
This bug was observed on at least three different machines with versions of FreeBSD from 5.4 to 6.2, no matters what: atausb or umass - was enabled in kernel.
Be sure to save any important work before trying next steps!
1. Insert USB Flash into a port, read from the console what special was assigned to the storage.
2. # mount_msdosfs /dev/daXsX /mnt
3. Manually remove flash drive from the computer.
4. # umount /dev/daXsX
System reports an error - Device not configured.
5. # umount -f /dev/daXsX
Watch your system rebooting or showing kernel panic message.
If you are not trying to perform the last command, you can still work and system will be stable, but when doing final shutdown with unmounting filesystems
the crash will certainly occur. The re-inserting of the drive cannot help avoid this - it will be recognized as new device.
The behaviour is always the same and doesn't depend on what type of filesystem is residing on a flash.
The only way to avoid such crash is to carefully monitor what flash drives are mounted, else the punishment will fall. But I'm sure this is not the way it should be handled.
Anyone is able to eject his(her) flash drive without unmounting by mistake - we all are humans. At least the system must not go down after such mistake.
May be a loss of data on the flash will occur - it's not so harmful. For desktop user this aspect is very important.
As I suppose this bug appears when mount syscall is trying to free some kernel-specific resourses, which were already free'd by some other mechanism -
probably GEOM. Crash's independence from used USB-driver framework(new atausb/old umass) confirms this assertion. Unfortunately, I don't have enough skills/time to resolve this myself.
There can be another approach - to write kernel-independed userspace filesystem based on FUSE libraries. But this will need too much duplicating work, will be not so flexible and may be too slow.
More information about the freebsd-bugs