Bug 212043 - panic when detaching USB mass storage
Summary: panic when detaching USB mass storage
Status: Closed DUPLICATE of bug 210316
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 11.0-RC1
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-22 07:54 UTC by martin
Modified: 2018-12-06 13:52 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description martin 2016-08-22 07:54:04 UTC
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
Comment 1 Hans Petter Selasky freebsd_committer freebsd_triage 2016-08-22 14:29:58 UTC
Hi,

This is not a USB subsystem bug, but general filesystem related.

--HPS
Comment 2 Warner Losh freebsd_committer freebsd_triage 2016-08-22 14:33:59 UTC
I suspect that we shouldn't be panicing in this case, but instead destroying the dirty buffer. The underlying device is gone, and we should have a flag in the mount that would tell us so (I believe), and we should not panic in this case.
Comment 3 Andriy Gapon freebsd_committer freebsd_triage 2016-08-23 07:29:26 UTC
Bug #210316 seems to be related.
Comment 4 Andriy Gapon freebsd_committer freebsd_triage 2018-12-06 13:52:57 UTC

*** This bug has been marked as a duplicate of bug 210316 ***