https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293382
--- Comment #10 from Paul <[email protected]> --- Hi, Absence of mem dumps was indeed an issue on our side. Finally we've got another panic with a memory dump, this time. This is the culprit: #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:405 #2 0xffffffff804a4718 in db_fncall_generic (nargs=0, args=0xfffffe2364ef9240, addr=<optimized out>, rv=<optimized out>) at /usr/src/sys/ddb/db_command.c:626 #3 db_fncall (dummy1=<optimized out>, dummy2=<optimized out>, dummy3=<optimized out>, dummy4=<optimized out>) at /usr/src/sys/ddb/db_command.c:674 #4 0xffffffff804a418d in db_command (last_cmdp=<optimized out>, cmd_table=<optimized out>, dopager=false) at /usr/src/sys/ddb/db_command.c:504 #5 0xffffffff804a42d6 in db_command_script (command=command@entry=0xffffffff81bba6e2 <db_recursion_data+18> "call doadump") at /usr/src/sys/ddb/db_command.c:569 #6 0xffffffff804a9578 in db_script_exec (scriptname=scriptname@entry=0xfffffe2364ef9410 "kdb.enter.panic", warnifnotfound=warnifnotfound@entry=0) at /usr/src/sys/ddb/db_script.c:302 #7 0xffffffff804a9472 in db_script_kdbenter (eventname=<optimized out>) at /usr/src/sys/ddb/db_script.c:324 #8 0xffffffff804a7531 in db_trap (type=<optimized out>, code=<optimized out>) at /usr/src/sys/ddb/db_main.c:267 #9 0xffffffff80bd0950 in kdb_trap (type=type@entry=3, code=code@entry=0, tf=tf@entry=0xfffffe2364ef9750) at /usr/src/sys/kern/subr_kdb.c:790 #10 0xffffffff810b3a07 in trap (frame=0xfffffe2364ef9750) at /usr/src/sys/amd64/amd64/trap.c:639 #11 <signal handler called> #12 kdb_enter (why=<optimized out>, msg=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:556 #13 0xffffffff80b7fc2d in vpanic (fmt=0xffffffff81257899 "mutex %s not owned at %s:%d", ap=ap@entry=0xfffffe2364ef9980) at /usr/src/sys/kern/kern_shutdown.c:953 #14 0xffffffff80b7f9f3 in panic (fmt=0xffffffff81d853a0 <cnputs_mtx> "\233\327\031\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:891 #15 0xffffffff80b5915f in __mtx_assert (c=<optimized out>, what=what@entry=4, file=0xffffffff812c1e07 "/usr/src/sys/kern/kern_cons.c", line=-1070498644, line@entry=290) at /usr/src/sys/kern/kern_mutex.c:1092 #16 0xffffffff80b23738 in kn_enter_flux (kn=0xfffff873f4f1e820) at /usr/src/sys/kern/kern_event.c:290 #17 kqueue_register (kq=kq@entry=0xfffff80189cb1c00, kev=kev@entry=0xfffffe2364ef9a40, td=td@entry=0xfffff80155304740, mflag=mflag@entry=2) at /usr/src/sys/kern/kern_event.c:1699 #18 0xffffffff80b24729 in kqueue_kevent (kq=kq@entry=0xfffff80189cb1c00, td=td@entry=0xfffff80155304740, nchanges=nchanges@entry=1, nevents=nevents@entry=0, k_ops=k_ops@entry=0xfffffe2364ef9de0, timeout=timeout@entry=0x0) at /usr/src/sys/kern/kern_event.c:1359 #19 0xffffffff80b245eb in kern_kevent_fp (td=td@entry=0xfffff80155304740, fp=<optimized out>, nchanges=nchanges@entry=1, nevents=nevents@entry=0, k_ops=k_ops@entry=0xfffffe2364ef9de0, timeout=timeout@entry=0x0) at /usr/src/sys/kern/kern_event.c:1390 #20 0xffffffff80b24502 in kern_kevent (td=td@entry=0xfffff80155304740, fd=<optimized out>, nchanges=1, nevents=0, k_ops=k_ops@entry=0xfffffe2364ef9de0, timeout=timeout@entry=0x0) at /usr/src/sys/kern/kern_event.c:1330 #21 0xffffffff80b24200 in kern_kevent_generic (td=0xfffff80155304740, uap=uap@entry=0xfffffe2364ef9db0, k_ops=k_ops@entry=0xfffffe2364ef9de0, struct_name=0xffffffff8127f5b9 "kevent") at /usr/src/sys/kern/kern_event.c:1186 #22 0xffffffff80b240f1 in sys_kevent (td=0xffffffff81d853a0 <cnputs_mtx>, uap=<optimized out>) at /usr/src/sys/kern/kern_event.c:1159 #23 0xffffffff810b4f0a in syscallenter (td=0xfffff80155304740) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:193 #24 amd64_syscall (td=0xfffff80155304740, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1241 #25 <signal handler called> #26 0x000000082f6dc3ea in ?? () Seems like a missing mutex assert is failing, which perfectly explains the racy nature of the issue. (kgdb) fr 16 #16 0xffffffff80b23738 in kn_enter_flux (kn=0xfffff873f4f1e820) at /usr/src/sys/kern/kern_event.c:290 290 KQ_OWNED(kn->kn_kq); (kgdb) l 285 286 static void 287 kn_enter_flux(struct knote *kn) 288 { 289 290 KQ_OWNED(kn->kn_kq); 291 MPASS(kn->kn_influx < INT_MAX); 292 kn->kn_influx++; 293 } (kgdb) p *kn $3 = { kn_link = { sle_next = 0x0 }, kn_selnext = { sle_next = 0x0 }, kn_knlist = 0xfffff83c698aa438, kn_tqe = { tqe_next = 0xffffffffffffffff, tqe_prev = 0xffffffffffffffff }, kn_kq = 0xfffff80164651600, kn_kevent = { ident = 267406, filter = -1, flags = 32, fflags = 0, data = 0, udata = 0x2c0901461480, ext = {0, 0, 0, 0} }, kn_hook = 0x0, kn_hookid = 0, kn_status = 0, kn_influx = 0, kn_sfflags = 0, kn_sdata = 0, kn_ptr = { p_fp = 0xfffff83f7bcf6b40, p_proc = 0xfffff83f7bcf6b40, p_aio = 0xfffff83f7bcf6b40, p_lio = 0xfffff83f7bcf6b40, p_v = 0xfffff83f7bcf6b40 }, kn_fop = 0xffffffff81437d38 <soread_filtops> } (kgdb) fr 18 #18 0xffffffff80b24729 in kqueue_kevent (kq=kq@entry=0xfffff80189cb1c00, td=td@entry=0xfffff80155304740, nchanges=nchanges@entry=1, nevents=nevents@entry=0, k_ops=k_ops@entry=0xfffffe2364ef9de0, timeout=timeout@entry=0x0) at /usr/src/sys/kern/kern_event.c:1359 1359 error = kqueue_register(kq, kevp, td, M_WAITOK); (kgdb) p *kevp $9 = { ident = 312462, filter = -1, flags = 2, fflags = 0, data = 0, udata = 0x0, ext = {0, 0, 0, 0} } Please, tell us, if you need more. -- You are receiving this mail because: You are the assignee for the bug.
