Bug 211959 - Kernel panic in devfs_fsync() -> ... -> g_vfs_strategy() in sys/geom/geom_vfs.c:173 on 11.0-RC1
Summary: Kernel panic in devfs_fsync() -> ... -> g_vfs_strategy() in sys/geom/geom_vfs...
Status: Closed DUPLICATE of bug 210316
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.0-RC1
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-fs mailing list
URL:
Keywords: panic
Depends on:
Blocks:
 
Reported: 2016-08-18 09:11 UTC by Piotr Kubaj
Modified: 2019-02-18 11:14 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 Piotr Kubaj 2016-08-18 09:11:26 UTC
I get a kernel panic when moving files from phone to HDD.

It happens after the upgrade from 10.3-RELEASE to 11.0-RC1. Seems to be related to VFS fixes which were committed recently. Unfortunately, I didn't use 11.0 before those fixes, so I can't say for sure.

(kgdb) bt
#0  doadump (textdump=<value optimized out>) at pcpu.h:221
#1  0xffffffff80549819 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0xffffffff80549dcb in vpanic (fmt=<value optimized out>, ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0xffffffff80549c03 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:690
#4  0xffffffff808a2691 in trap_fatal (frame=0xfffffe04697f7750, eva=0) at /usr/src/sys/amd64/amd64/trap.c:841
#5  0xffffffff808a2320 in trap (frame=0xfffffe04697f7750) at /usr/src/sys/amd64/amd64/trap.c:203
#6  0xffffffff80887041 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236
#7  0xffffffff804bfd1c in g_vfs_strategy (bo=0xfffff80188ae7658, bp=0xfffffe03e2887370) at /usr/src/sys/geom/geom_vfs.c:173
#8  0xffffffff805f6e89 in bufwrite (bp=0xfffffe03e2887370) at buf.h:405
#9  0xffffffff80606040 in vop_stdfsync (ap=0xfffffe04697f79a8) at /usr/src/sys/kern/vfs_default.c:695
#10 0xffffffff80442d06 in devfs_fsync (ap=0xfffffe04697f79a8) at /usr/src/sys/fs/devfs/devfs_vnops.c:702
#11 0xffffffff808f6e7d in VOP_FSYNC_APV (vop=<value optimized out>, a=<value optimized out>) at vnode_if.c:1331
#12 0xffffffff8061e66e in sched_sync () at vnode_if.h:549
#13 0xffffffff8050a275 in fork_exit (callout=0xffffffff8061e2b0 <sched_sync>, arg=0x0, frame=0xfffffe04697f7a40) at /usr/src/sys/kern/kern_fork.c:1038
#14 0xffffffff8088750e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611
#15 0x0000000000000000 in ?? ()
(kgdb) up 7
#7  0xffffffff804bfd1c in g_vfs_strategy (bo=0xfffff80188ae7658, bp=0xfffffe03e2887370) at /usr/src/sys/geom/geom_vfs.c:173
173		mtx_lock(&sc->sc_mtx);
(kgdb) list
168		sc = cp->geom->softc;
169	
170		/*
171		 * If the provider has orphaned us, just return EXIO.
172		 */
173		mtx_lock(&sc->sc_mtx);
174		if (sc->sc_orphaned) {
175			mtx_unlock(&sc->sc_mtx);
176			bp->b_error = ENXIO;
177			bp->b_ioflags |= BIO_ERROR;
(kgdb) print bo
$1 = (struct bufobj *) 0xfffff80188ae7658
(kgdb) print *bo
$2 = {bo_lock = {lock_object = {lo_name = 0xffffffff80969cd9 "bufobj interlock", lo_flags = 86179840, lo_data = 0, lo_witness = 0x0}, rw_lock = 1}, bo_ops = 0xffffffff80bf1c08, bo_object = 0xfffff8033d02dd68, bo_synclist = {le_next = 0x0, le_prev = 0xfffff800084b0670}, 
  bo_private = 0xfffff80188ae7588, __bo_vnode = 0xfffff80188ae7588, bo_clean = {bv_hd = {tqh_first = 0xfffffe03e2886f10, tqh_last = 0xfffffe03e2962ab0}, bv_root = {pt_root = 18446735277816184480}, bv_cnt = 1501}, bo_dirty = {bv_hd = {tqh_first = 0x0, 
      tqh_last = 0xfffff80188ae76c8}, bv_root = {pt_root = 0}, bv_cnt = 0}, bo_numoutput = 1, bo_flag = 0, bo_bsize = 512}
(kgdb) print *bp
$3 = {b_bufobj = 0xfffff80188ae7658, b_bcount = 4096, b_caller1 = 0x0, b_data = 0xfffffe03e6398000 "���\017���\017���\017���\017���\017", b_error = 0, b_iocmd = 2, b_ioflags = 2, b_iooffset = 16384, b_resid = 0, b_iodone = 0, b_blkno = 32, b_offset = 16384, b_bobufs = {
    tqe_next = 0xfffffe03e2892040, tqe_prev = 0xfffffe03e2887190}, b_vflags = 1, b_qindex = 2, b_flags = 2684354596, b_xflags = 2 '\002', b_lock = {lock_object = {lo_name = 0xffffffff80967645 "bufwait", lo_flags = 108199936, lo_data = 0, lo_witness = 0x0}, 
    lk_lock = 18446744073709551600, lk_exslpfail = 0, lk_timo = 0, lk_pri = 96}, b_bufsize = 4096, b_runningbufspace = 4096, b_kvasize = 16384, b_dirtyoff = 0, b_dirtyend = 0, b_kvabase = 0xfffffe03e6398000 "���\017���\017���\017���\017���\017", b_lblkno = 32, 
  b_vp = 0xfffff80188ae7588, b_rcred = 0x0, b_wcred = 0x0, {b_freelist = {tqe_next = 0xfffffe03e2959140, tqe_prev = 0xffffffff80e67aa0}, {b_pgiodone = 0xfffffe03e2959140, b_pgbefore = -2132378976, b_pgafter = -1}}, b_cluster = {cluster_head = {
      tqh_first = 0xfffffe03e2887140, tqh_last = 0xfffffe03e2822ec0}, cluster_entry = {tqe_next = 0xfffffe03e2887140, tqe_prev = 0xfffffe03e2822ec0}}, b_pages = 0xfffffe03e2887470, b_npages = 1, b_dep = {lh_first = 0x0}, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, 
  b_fsprivate3 = 0x0, b_pin_count = 0}
(kgdb) print sc
$4 = (struct g_vfs_softc *) 0x2e776f6c6c610065
(kgdb) print *sc
Cannot access memory at address 0x2e776f6c6c610065


If there's anything else I can check, please ask.
Comment 1 Piotr Kubaj 2016-09-15 08:57:42 UTC
I'm not sure but the error may be related to KDE. It happens only on PC's that use KDE and 11.0, others are unaffected.
Comment 2 Andriy Gapon freebsd_committer 2019-02-18 11:14:24 UTC

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