Re: detaching usb device without unmounting it

hmmm...i just tried that:

1. attach the device
2. mount the device _at_ mnt/umass
3. detach the device
4. do `umount -f /mnt/umass`

i got the same error message i got when not using the f switch. also i forget
to mention this lor:

Jul 10 16:26:24 otaku kernel: lock order reversal:
Jul 10 16:26:24 otaku kernel: 1st 0xc81569c0 ufs (ufs) _at_
/usr/src/sys/kern/vfs_mount.c:1199
Jul 10 16:26:24 otaku kernel: 2nd 0xc8dec9c0 devfs (devfs) _at_
/usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:944
Jul 10 16:26:24 otaku kernel: KDB: stack backtrace:
Jul 10 16:26:24 otaku kernel:
db_trace_self_wrapper(c07d787b,ea61ca3c,c0609a25,c05fa4db,c07da81e,...) at
db_trace_self_wrapper+0x26
Jul 10 16:26:24 otaku kernel:
kdb_backtrace(c05fa4db,c07da81e,c78f0bc0,c78f0af0,ea61ca98,...) at
kdb_backtrace+0x29
Jul 10 16:26:24 otaku kernel:
_witness_debugger(c07da81e,c8dec9c0,c07c9650,c78f0af0,c07c9f08,...) at
_witness_debugger+0x25
Jul 10 16:26:24 otaku kernel:
witness_checkorder(c8dec9c0,9,c07c9f08,3b0,c8deca28,...) at
witness_checkorder+0x839
Jul 10 16:26:24 otaku kernel: __lockmgr_args(c8dec9c0,80400,c8deca28,0,0,...)
at __lockmgr_args+0x7b7
Jul 10 16:26:24 otaku kernel:
vop_stdlock(ea61cba0,c09abbc8,c8a8ee24,80400,c8dec968,...) at vop_stdlock+0x68
Jul 10 16:26:24 otaku kernel:
VOP_LOCK1_APV(c0820980,ea61cba0,ea61cbc0,c0853f80,c8dec968,...) at
VOP_LOCK1_APV+0xb5
Jul 10 16:26:24 otaku kernel:
_vn_lock(c8dec968,80400,c07c9f08,3b0,c7ea35a0,...) at _vn_lock+0x78
Jul 10 16:26:24 otaku kernel: msdosfs_sync(c7ea35a0,1,ea61cc38,4f4,80,...) at
msdosfs_sync+0x29c
Jul 10 16:26:24 otaku kernel: dounmount(c7ea35a0,8080000,c8a8ed80,479,1,...)
at dounmount+0x44e
Jul 10 16:26:24 otaku kernel: unmount(c8a8ed80,ea61ccf8,8,65,c,...) at
unmount+0x2bf
Jul 10 16:26:24 otaku kernel: syscall(ea61cd38) at syscall+0x2a6
Jul 10 16:26:24 otaku kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20
Jul 10 16:26:24 otaku kernel: --- syscall (22, FreeBSD ELF32, unmount), eip =
0x280d730f, esp = 0xbfbfe4bc, ebp = 0xbfbfe588 ---

again i can't get back to the shell using ctrl+c. switching to another console
and issuing a reboot stalls at the very same point.

alex

M. Warner Losh schrieb am 2009-07-10:
> In message:
> <permail-20090710090548f7e55a9d00003ae0-a_best01_at_message-id.uni-muenster.de>
>             Alexander Best <alexbestms_at_math.uni-muenster.de> writes:
> : since the usb2 stack allows one to detach a mounted usb device
>   without the
> : kernel panic'ing

> usb1 allowed that too.  the problem rarely was inside the usb stack
> (although there were some problems).  The problem was at the higher
> levels of cam, the buffer cache and the file system.  There were
> changes scattered throughout the rest of the system to allow devices
> to suddenly disappear.  All usb2 did was fix a few edge cases in usb.

> : i'd like to know which steps are necessary to be taken after
> : detaching a device? because i tried the following:
> :
> : 1. attach device
> : 2. mount device
> : 3. detach device
> :
> : when i tried to unmount the device i got the follwing error
>   message:
> :
> : g_vfs_done():label/usb[WRITE(offset=19456, length=4096)]error = 6

> The proper action is limited to 'umount -f'.  You can't reattach it,
> you can't really touch any files in the system (some cached files
> might be ok), you certainly can't write to it.

> : and the console got locked up (ctr+c didn't work). so i tried to
>   reboot using
> : ctrl+alt+del. however after the message: "All buffers synced" there
>   was no
> : reboot. so i had to do a hard reset. however after the reset
>   freebsd fsck'ed
> : my harddrives. so they didn't unmount properly.
> :
> : should i have used `umount -f`? or just plug the device back in
>   again? or
> : isn't it possible to unmount a device that has already been
>   detached?

> You should have done an umount -f.  You can't plug it back in again
> because we don't have support at the right levels (CAM(?), GEOM,
> buffer cache, fs) to allow previously orphaned resources to be
> reconnected to a new device.  The device was destroyed, and data was
> destroyed with it...

> Warner