Date: Thu, 19 Jul 2018 10:46:41 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 229887] zfs quota related panic: solaris assert: 0 == dmu_tx_assign(tx, TXG_WAIT), Message-ID: <bug-229887-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229887 Bug ID: 229887 Summary: zfs quota related panic: solaris assert: 0 =3D=3D dmu_tx_assign(tx, TXG_WAIT), Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: bugzilla.freebsd@omnilan.de Hello, today my PC locked up while using local Xorg. After hard reset, I got the following panic: solaris assert: 0 =3D=3D dmu_tx_assign(tx, TXG_WAIT), file: /usr/local/share/deploy-tools/HEAD/src/sys/cddl/contrib/opensolaris/uts/com= mon/fs/zfs/zfs_dir.c, line: 330 assfail() at assfail+0x1a/frame 0xfffffe008cd842e0 zfs_unlinked_drain() at zfs_unlinked_drain+0x175/frame 0xfffffe008cd844b0 zfsvfs_setup() at zfsvfs_setup+0x5b/frame 0xfffffe008cd844e0 zfs_mount() at zfs_mount+0x731/frame 0xfffffe008cd84670 vfs_domount() at vfs_domount+0x730/frame 0xfffffe008cd84890 vfs_donmount() at vfs_donmount+0x807/frame 0xfffffe008cd84940 sys_nmount() at sys_nmount+0x72/frame 0xfffffe008cd84980 amd64_syscall() at amd64_syscall+0x281/frame 0xfffffe008cd84ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe008cd84ab0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip =3D 0x80037684a, rsp =3D 0x7fffffffcc68, rbp =3D 0x7fffffffcce0 --- #11 0xffffffff81eb523a in assfail () from /boot/kernel/opensolaris.ko #12 0xffffffff81b806a5 in zfs_unlinked_drain () from /boot/kernel/zfs.ko #13 0xffffffff81b997fb in zfsvfs_setup () from /boot/kernel/zfs.ko #14 0xffffffff81b972a1 in zfs_mount () from /boot/kernel/zfs.ko #15 0xffffffff808b44f0 in vfs_domount (td=3D0xfffffe008cd84368, fstype=3D<v= alue optimized out>, fspath=3D<value optimized out>,=20 fsflags=3D<value optimized out>, optlist=3D0xfffffe008cd848d8) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/vfs_mount.c:892 #16 0xffffffff808b37b7 in vfs_donmount (td=3D0xfffff800110d2000, fsflags=3D= 0, fsoptions=3D0xfffff8000e16e100) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/vfs_mount.c:726 #17 0xffffffff808b2f82 in sys_nmount (td=3D0xfffff800110d2000, uap=3D0xfffff800110d23c0) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/vfs_mount.c:431 #18 0xffffffff80b39771 in amd64_syscall (td=3D0xfffff800110d2000, traced=3D= 0) at subr_syscall.c:135 #19 0xffffffff80b1586d in fast_syscall_common () at /usr/local/share/deploy-tools/HEAD/src/sys/amd64/amd64/exception.S:500 #20 0x000000080037684a in ?? () After I found the suspicious dataset which cused that panic due to quota exhaustion, there was another (single user) panic, which I haven't dumped to swap because this one wassn't saved yet... So here's just the kdb lines, transcribed manually from a picture I took: panic: solaris assert: delta > 0 ? dsl_dir_phys(dd)->dd_used_breakdown[oldt= ype] >=3D delt :-( missing rest of the line :-( /dsl_dir.c, line 1564 =E2=80=A6 assfail() dsl_dir_transfer_space() at dsl_dir_transfer_space dsl_dataset_block_born() at dsl_dataset_block_born dbuf_write_done() at dbuf_write_done arc_write_done() at arc_write_done zio_done() at zio_done zio_execute() at zio_execute taskqueue_run_locked() at taskqueue_run_locked taskqueue_thread_loop() at taskqueue_thread_loop fork_exit() at fork_exit fork_trampoline() at fork_trampoline Since it's a custom kernel, the latter is useless I guess, but in case some= body considers this kind of crash worth fixing, the second partly trace might po= int to other places in the same context. Will try to get to the sources and add a more useful backtrace, don't have = them arround and ran out of time now... Thanks, -harry --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-229887-227>