On Mon, Apr 06, 2020 at 02:19:25PM -0700, Eric Joyner wrote: > Mark, > > I think I was mistaken about the backtrace looking the same. I was looking > at it from within ddb, and I think I focused on the > epoch_block_handler_preempt line and didn't notice that it only stopped > there this time. Here's the new one I've got from kgdb:
Thanks. Could you try to print "td->td_name" from frame 4? It should also be available as er->er_blockedtd. Basically, I'm trying to verify that the interrupt thread itself isn't the one that we're waiting for, else there is another bug to be fixed. If you can provide kernel symbols and vmcore, I'd be happy to look at it myself. > #0 cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1448 > #1 0xffffffff80ff2f79 in ipi_nmi_handler () at > /usr/src/sys/x86/x86/mp_x86.c:1405 > #2 0xffffffff810294a6 in trap (frame=0xfffffe003b9b6f30) at > /usr/src/sys/amd64/amd64/trap.c:201 > #3 <signal handler called> > #4 epoch_block_handler_preempt (global=0xfffff80003de0100, > cr=0xfffffe00dee85900, arg=0x0) at /usr/src/sys/kern/subr_epoch.c:507 > #5 0xffffffff803b576d in epoch_block (global=0xfffff80003de0100, > cr=0xfffffe00dee85900, cb=0xffffffff80bcf190 <epoch_block_handler_preempt>, > ct=0x0) at /usr/src/sys/contrib/ck/src/ck_epoch.c:416 > #6 ck_epoch_synchronize_wait (global=0xfffff80003de0100, cb=<optimized > out>, ct=<optimized out>) at /usr/src/sys/contrib/ck/src/ck_epoch.c:465 > #7 0xffffffff80bcf03c in epoch_wait_preempt (epoch=0xfffff80003de0100) at > /usr/src/sys/kern/subr_epoch.c:529 > #8 0xffffffff80c9410a in if_detach_internal (ifp=0xfffff80067ed4000, > vmove=0, ifcp=0x0) at /usr/src/sys/net/if.c:1123 > #9 0xffffffff80c93ebd in if_detach (ifp=0xfffff80003de0100) at > /usr/src/sys/net/if.c:1063 > #10 0xffffffff80cafa56 in iflib_device_deregister (ctx=0xfffff80088c91800) > at /usr/src/sys/net/iflib.c:5104 > #11 0xffffffff80bc1e2e in DEVICE_DETACH (dev=0xfffff80004706a00) at > ./device_if.h:234 > #12 device_detach (dev=0xfffff80004706a00) at > /usr/src/sys/kern/subr_bus.c:3049 > #13 0xffffffff80bc13fd in devclass_driver_deleted > (busclass=0xfffff80004352900, dc=0xfffff80004385a00, > driver=0xffffffff823329e0 <i40e_read_nvm_buffer_aq+352>) at > /usr/src/sys/kern/subr_bus.c:1235 > #14 0xffffffff80bc12ef in devclass_delete_driver > (busclass=0xfffff80004352900, driver=0xffffffff823329e0 > <i40e_read_nvm_buffer_aq+352>) at /usr/src/sys/kern/subr_bus.c:1310 > #15 0xffffffff80bc721c in driver_module_handler (mod=0xfffff80015cd8680, > what=1, arg=0xffffffff823329b0 <i40e_read_nvm_buffer_aq+304>) at > /usr/src/sys/kern/subr_bus.c:5229 > #16 0xffffffff80b67b82 in module_unload (mod=0xfffff80015cd8680) at > /usr/src/sys/kern/kern_module.c:261 > #17 0xffffffff80b5895b in linker_file_unload (file=0xfffff8016da69a00, > flags=0) at /usr/src/sys/kern/kern_linker.c:700 > #18 0xffffffff80b59dad in kern_kldunload (td=<optimized out>, fileid=5, > flags=0) at /usr/src/sys/kern/kern_linker.c:1153 > #19 0xffffffff8102aa40 in syscallenter (td=<optimized out>) at > /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:162 > #20 amd64_syscall (td=0xfffffe00e839f100, traced=0) at > /usr/src/sys/amd64/amd64/trap.c:1161 > #21 <signal handler called> > #22 0x00000008002ddcba in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffffffe188 > > - Eric _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
