USB mass storage can throw a panic when detaching a device. It is not reproducible easily, probably it occurred due to unlucky race.

Here the system (I fetch from Github):
FreeBSD 11.0-RC1 FreeBSD 11.0-RC1 #0 r304179+b38c18f(releng/11.0)

kgdb output (redacted some names and IDs for privacy):


/var/crash # kgdb /boot/kernel/kernel vmcore.9
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
(da6:umass-sim1:1:0:2): READ(10). CDB: 28 40 00 17 81 80 00 00 80 00 
(da6:umass-sim1:1:0:2): CAM status: CCB request completed with an error
(da6:umass-sim1:1:0:2): Retrying command
(da6:umass-sim1:1:0:2): READ(10). CDB: 28 40 00 17 81 80 00 00 80 00 
(da6:umass-sim1:1:0:2): CAM status: CCB request completed with an error
(da6:umass-sim1:1:0:2): Retrying command
(da6:umass-sim1:1:0:2): READ(10). CDB: 28 40 00 17 81 80 00 00 80 00 
(da6:umass-sim1:1:0:2): CAM status: CCB request completed with an error
(da6:umass-sim1:1:0:2): Retrying command
(da6:umass-sim1:1:0:2): READ(10). CDB: 28 40 00 17 81 80 00 00 80 00 
(da6:umass-sim1:1:0:2): CAM status: CCB request completed with an error
(da6:umass-sim1:1:0:2): Retrying command
(da6:umass-sim1:1:0:2): READ(10). CDB: 28 40 00 17 81 80 00 00 80 00 
(da6:umass-sim1:1:0:2): CAM status: CCB request completed with an error
(da6:umass-sim1:1:0:2): Error 5, Retries exhausted
g_vfs_done():da6s1[WRITE(offset=512, length=512)]error = 5
g_vfs_done():da6s1[READ(offset=784531456, length=65536)]error = 5
fsync: giving up on dirty
0xfffff801c9c5ace8: tag devfs, type VCHR
    usecount 1, writecount 0, refcount 125 mountedhere 0xfffff8001ab11c00
    flags (VI_ACTIVE)
    v_object 0xfffff80058267e70 ref 0 pages 144 cleanbuf 122 dirtybuf 1
    lock type devfs: EXCL by thread 0xfffff80117a2d000 (pid 28717, umount, tid 101785)
        dev da6s1
da4 at umass-sim1 bus 1 scbus7 target 0 lun 0
da4: <XXXXXXXX XXXXXXXXXXXXX 1.01> s/n 44CA35630BB5AA1A detached
da5 at umass-sim1 bus 1 scbus7 target 0 lun 1
da5: <XXXXXXXX XXXXXXXXXXXXX 1.01> s/n 44CA35630BB5AA1A detached
da6 at umass-sim1 bus 1 scbus7 target 0 lun 2
(da4:da6: umass-sim1:1:<XXXXXXXX XXXXXXXXXXXXXXX 1.01>0: s/n 44CA35630BB5AA1A):  detached
Periph destroyed
(da6:umass-sim1:1:0:2): Periph destroyed
(da5:umass-sim1:1:0:1): Periph destroyed
umodem0: at uhub0, port 3, addr 1 (disconnected)
Device da6s1 went missing before all of the data could be written to it; expect data loss.
fsync: giving up on dirty
0xfffff801c9c5ace8: tag devfs, type VCHR
    usecount 1, writecount 0, refcount 126 mountedhere 0xfffff8001ab11c00
    flags (VI_DOOMED|VI_ACTIVE)
    v_object 0xfffff80058267e70 ref 0 pages 144 cleanbuf 122 dirtybuf 1
    lock type devfs: EXCL by thread 0xfffff801c4cd0000 (pid 29470, realpath, tid 101868)
        dev da6s1
panic: devfs_fsync: vop_stdfsync failed.
cpuid = 2
KDB: stack backtrace:
#0 0xffffffff80b218e7 at kdb_backtrace+0x67
#1 0xffffffff80ad9312 at vpanic+0x182
#2 0xffffffff80ad9183 at panic+0x43
#3 0xffffffff80985b0f at devfs_fsync+0x8f
#4 0xffffffff8110b03d at VOP_FSYNC_APV+0x8d
#5 0xffffffff80b89a65 at bufsync+0x35
#6 0xffffffff80ba93e0 at bufobj_invalbuf+0x160
#7 0xffffffff80bacede at vgonel+0x1fe
#8 0xffffffff80bad651 at vgone+0x81
#9 0xffffffff8097e6a4 at devfs_delete+0x304
#10 0xffffffff8097ec3f at devfs_populate_loop+0x20f
#11 0xffffffff8097ea1a at devfs_populate+0x2a
#12 0xffffffff80984ca7 at devfs_populate_vp+0xc7
#13 0xffffffff8098333e at devfs_getattr+0x1e
#14 0xffffffff8110a577 at VOP_GETATTR_APV+0x87
#15 0xffffffff80bbd693 at vn_stat+0xa3
#16 0xffffffff80bb6a9e at kern_statat+0xde
#17 0xffffffff80bb6c50 at sys_lstat+0x30
Uptime: 7h53m45s

--
Martin Sugioarto