Bug 205166 - OS craching on USB connection.
Summary: OS craching on USB connection.
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.2-STABLE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-09 19:50 UTC by agniaus
Modified: 2024-01-13 23:39 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description agniaus 2015-12-09 19:50:55 UTC
I have home server:
http://www.gigabyte.com/products/product-page.aspx?pid=5118#ov
this computer have 3 USB ports, two USB 2.0 and one USB 3.0. On USB 2.0 ports I have two external USB storages and they are mirrored with gmirror. When I connect USB 3.0 storage to USB 3.0 port OS crashing or new attached on top of one of USB 2.0. For example:
Dec  4 09:56:26 server kernel: da0 at umass-sim0 bus 0 scbus1 target 0 lun 0
Dec  4 09:56:26 server kernel: da0: <WD 5000AAV External 1.65> Fixed Direct Access SPC-2 SCSI device
Dec  4 09:56:26 server kernel: da0: Serial Number 57442D574341554631333931313437
Dec  4 09:56:26 server kernel: da0: 40.000MB/s transfers
Dec  4 09:56:26 server kernel: da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
Dec  4 09:56:26 server kernel: da0: quirks=0x2<NO_6_BYTE>
Dec  4 09:56:26 server kernel: da1 at umass-sim1 bus 1 scbus2 target 0 lun 0
Dec  4 09:56:26 server kernel: da1: <WD 5000AAV External 1.65> Fixed Direct Access SPC-2 SCSI device
Dec  4 09:56:26 server kernel: da1: Serial Number 57442D574341554631343634353130
Dec  4 09:56:26 server kernel: da1: 40.000MB/s transfers
Dec  4 09:56:26 server kernel: da1: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
Dec  4 09:56:26 server kernel: da1: quirks=0x2<NO_6_BYTE>

On top on da1:
Dec  4 21:39:32 server kernel: da1 at umass-sim1 bus 1 scbus2 target 0 lun 0
Dec  4 21:39:32 server kernel: da1: <ASMT 2105 0> Fixed Direct Access SPC-4 SCSI device
Dec  4 21:39:32 server kernel: da1: Serial Number 123456789012
Dec  4 21:39:32 server kernel: da1: 400.000MB/s transfers
Dec  4 21:39:32 server kernel: da1: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C)
Dec  4 21:39:32 server kernel: da1: quirks=0x2<NO_6_BYTE>
Dec  4 21:41:28 server kernel: da1 at umass-sim1 bus 1 scbus2 target 0 lun 0
Dec  4 21:41:28 server kernel: da1: <ASMT 2105 0> s/n 123456789012 detached

Crash example:

Dec  4 09:56:26 server syslogd: kernel boot file is /boot/kernel/kernel
Dec  4 09:56:26 server kernel: panic: initiate_write_inodeblock_ufs2: already started
Dec  4 09:56:26 server kernel: cpuid = 0
Dec  4 09:56:26 server kernel: KDB: stack backtrace:
Dec  4 09:56:26 server kernel: #0 0xffffffff80984e30 at kdb_backtrace+0x60
Dec  4 09:56:26 server kernel: #1 0xffffffff809489e6 at vpanic+0x126
Dec  4 09:56:26 server kernel: #2 0xffffffff809488b3 at panic+0x43
Dec  4 09:56:26 server kernel: #3 0xffffffff80b84c1a at softdep_disk_io_initiation+0x10ca
Dec  4 09:56:26 server kernel: #4 0xffffffff80ba432e at ffs_geom_strategy+0x15e
Dec  4 09:56:26 server kernel: #5 0xffffffff809d0372 at bufwrite+0x142
Dec  4 09:56:26 server kernel: #6 0xffffffff809d2ac1 at vfs_bio_awrite+0x3d1
Dec  4 09:56:26 server kernel: #7 0xffffffff809dc7a1 at vop_stdfsync+0x241
Dec  4 09:56:26 server kernel: #8 0xffffffff8082f306 at devfs_fsync+0x26
Dec  4 09:56:26 server kernel: #9 0xffffffff80e72a47 at VOP_FSYNC_APV+0xa7
Dec  4 09:56:26 server kernel: #10 0xffffffff809efc8b at sched_sync+0x3ab
Dec  4 09:56:26 server kernel: #11 0xffffffff8091244a at fork_exit+0x9a
Comment 1 Hans Petter Selasky freebsd_committer freebsd_triage 2015-12-09 21:01:41 UTC
From the backtrace this is not an USB issue, but a generic filesystem issue.
Comment 2 agniaus 2015-12-10 17:15:43 UTC
I put wrong kernel panic log:
Dec  8 18:59:33 server kernel: Fatal trap 12: page fault while in kernel mode
Dec  8 18:59:33 server kernel: cpuid = 0; apic id = 00
Dec  8 18:59:33 server kernel: fault virtual address    = 0x378
Dec  8 18:59:33 server kernel: fault code               = supervisor read data, page not present
Dec  8 18:59:33 server kernel: instruction pointer      = 0x20:0xffffffff80950ceb
Dec  8 18:59:33 server kernel: stack pointer            = 0x28:0xfffffe00f0f86970
Dec  8 18:59:33 server kernel: frame pointer            = 0x28:0xfffffe00f0f86a30
Dec  8 18:59:33 server kernel: code segment             = base rx0, limit 0xfffff, type 0x1b
Dec  8 18:59:33 server kernel: = DPL 0, pres 1, long 1, def32 0, gran 1
Dec  8 18:59:33 server kernel: processor eflags = interrupt enabled, resume, IOPL = 0
Dec  8 18:59:33 server kernel: current process          = 13 (g_event)
Dec  8 18:59:33 server kernel: trap number              = 12
Dec  8 18:59:33 server kernel: panic: page fault
Dec  8 18:59:33 server kernel: cpuid = 0
Dec  8 18:59:33 server kernel: KDB: stack backtrace:
Dec  8 18:59:33 server kernel: #0 0xffffffff80984e30 at kdb_backtrace+0x60
Dec  8 18:59:33 server kernel: #1 0xffffffff809489e6 at vpanic+0x126
Dec  8 18:59:33 server kernel: #2 0xffffffff809488b3 at panic+0x43
Dec  8 18:59:33 server kernel: #3 0xffffffff80d4aa8b at trap_fatal+0x36b
Dec  8 18:59:33 server kernel: #4 0xffffffff80d4ad8d at trap_pfault+0x2ed
Dec  8 18:59:33 server kernel: #5 0xffffffff80d4a42a at trap+0x47a
Dec  8 18:59:33 server kernel: #6 0xffffffff80d307a2 at calltrap+0x8
Dec  8 18:59:33 server kernel: #7 0xffffffff809507fd at _sx_xlock+0x5d
Dec  8 18:59:33 server kernel: #8 0xffffffff819a2010 at g_mirror_access+0x100
Dec  8 18:59:33 server kernel: #9 0xffffffff808ab74e at g_access+0x14e
Dec  8 18:59:33 server kernel: #10 0xffffffff808ad017 at g_vfs_orphan+0xc7
Dec  8 18:59:33 server kernel: #11 0xffffffff808a7c77 at g_run_events+0x237
Dec  8 18:59:33 server kernel: #12 0xffffffff8091244a at fork_exit+0x9a
Comment 3 Warner Losh freebsd_committer freebsd_triage 2024-01-13 23:39:42 UTC
This sure looks weird....
However, it's against a version of FreeBSD that has gone out of support.
If this problem can be reproduced on FreeBSD 13 or newer, please file a new bug so our triage processes get it on our radar.