Bug 203419 - solaris assert: (dn->dn_phys->dn_nlevels == 0 && db->db_level == ...
Summary: solaris assert: (dn->dn_phys->dn_nlevels == 0 && db->db_level == ...
Status: Closed Feedback Timeout
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
URL: https://lists.freebsd.org/pipermail/f...
Keywords: crash, needs-patch, needs-qa
Depends on:
Blocks:
 
Reported: 2015-09-28 16:16 UTC by mikej
Modified: 2017-03-12 09:53 UTC (History)
2 users (show)

See Also:
koobs: mfc-stable11?
koobs: mfc-stable10?

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description mikej 2015-09-28 16:16:47 UTC 
FreeBSD 11.0-CURRENT #0 r288019

Kernel panics while running poudriere. These panics started after upgrading from r287325.

Dump header from device: /dev/da2p1
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 3141214208
  Blocksize: 512
  Dumptime: Mon Sep 28 08:19:47 2015
  Hostname: bsd11
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 11.0-CURRENT #0 r288019: Sun Sep 20 17:16:46 EDT 2015
    mikej@bsd11:/usr/obj/usr/src/sys/GENERIC
  Panic String: solaris assert: (dn->dn_phys->dn_nlevels == 0 && db->db_level ==
0) || dn->dn_phys->dn_nlevels > db->db_level || dn->dn_next_nlevels[txgoff] >
db->db_level || dn->dn_next_nlevels[(tx->tx_txg-
  Dump Parity: 1563774101
  Bounds: 2
  Dump Status: good

https://charon.gopai.com/info.2
https://charon.gopai.com/core.txt.2
https://charon.gopai.com/vmcore.2
Comment 1 Andriy Gapon freebsd_committer freebsd_triage 2016-07-18 17:11:37 UTC 
Please attach core.txt.2 to the bug, so that it does not disappear like it already has.
Comment 2 Andriy Gapon freebsd_committer freebsd_triage 2017-03-12 09:53:49 UTC 
For posterity, link to another case where the problem happened:
https://lists.freebsd.org/pipermail/freebsd-current/2016-July/062281.html

Here is a stack trace from the link:
panic: solaris assert: (dn->dn_phys->dn_nlevels == 0 && db->db_level == 0) || dn->dn_phys->dn_nlevels > db->db_level || dn->dn_next_nlevels[txgoff] > db->db_level || dn->dn_next_nlevels[(tx->tx_txg-1) & TXG_MASK] > db->db_level || dn->dn_next_nlevels[(tx->tx_txg
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085a435eb0
vpanic() at vpanic+0x182/frame 0xfffffe085a435f30
panic() at panic+0x43/frame 0xfffffe085a435f90
assfail() at assfail+0x1a/frame 0xfffffe085a435fa0
dbuf_dirty() at dbuf_dirty+0x3e8/frame 0xfffffe085a436060
dbuf_dirty() at dbuf_dirty+0xba4/frame 0xfffffe085a436120
dbuf_dirty() at dbuf_dirty+0xba4/frame 0xfffffe085a4361e0
dmu_write_uio_dnode() at dmu_write_uio_dnode+0x129/frame 0xfffffe085a436270
dmu_write_uio_dbuf() at dmu_write_uio_dbuf+0x42/frame 0xfffffe085a4362a0
zfs_freebsd_write() at zfs_freebsd_write+0x87c/frame 0xfffffe085a4364c0
VOP_WRITE_APV() at VOP_WRITE_APV+0x16f/frame 0xfffffe085a4365d0
vn_write() at vn_write+0x218/frame 0xfffffe085a436650
vn_io_fault1() at vn_io_fault1+0x1d2/frame 0xfffffe085a4367b0
vn_io_fault() at vn_io_fault+0x197/frame 0xfffffe085a436830
dofilewrite() at dofilewrite+0x87/frame 0xfffffe085a436880
kern_writev() at kern_writev+0x68/frame 0xfffffe085a4368d0
sys_write() at sys_write+0x84/frame 0xfffffe085a436920
amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe085a436a30
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe085a436a30
--- syscall (4, FreeBSD ELF64, sys_write), rip = 0x800b9ddea, rsp = 0x7fffffffe568, rbp = 0x7fffffffe760 ---
KDB: enter: panic

That instance was not diagnosed too.