On 24.09.2019 10:27, Patrick Welche wrote: > Just found a netbsd.0.core left behind at the time daily would have run, > which would have coincided with a pbulk run (judging from just how many > nbmake processe there are.) > > (Yesterday's -current/amd64) > > crash> bt > _KERNEL_OPT_NARCNET() at 0 > ?() at ffffb5013ded4000 > vpanic() at vpanic+0x14c > snprintf() at snprintf > startlwp() at startlwp > calltrap() at calltrap+0x11 > crash> ps > PID LID S CPU FLAGS STRUCT LWP * NAME WAIT > 0 > 68 7 2 200 ffff93e2bf3b7300 iic0 > 0 > 41 7 5 201 ffff93e2beffd1e0 idle/5 > 0 > 17 7 1 201 ffff93e2beeb30e0 idle/1 > 0 > 10 7 6 200 ffff93e5d0bda900 cachegc > 0 > 5 7 0 200 ffff93e5d0bf4060 softclk/0 > 0 > 1 7 0 200 ffffffff80c374a0 swapper > > Reading symbols from netbsd.0... > (No debugging symbols found in netbsd.0) > (gdb) symbol-file netbsd.0.gdb > Reading symbols from netbsd.0.gdb... > (gdb) target kvm netbsd.0.core > 0xffffffff8022130a in cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at ../../../../arch/amd64/amd64/machdep.c:728 > 728 dumpsys(); > (gdb) thread apply all bt > > Thread 2.1 (<kvm>): > #0 0xffffffff8022130a in cpu_reboot (howto=howto@entry=260, bootstr=bootstr@entry=0x0) at ../../../../arch/amd64/amd64/machdep.c:728 > #1 0xffffffff8062f500 in vpanic (fmt=fmt@entry=0xffffffff80925ce0 "trap", ap=ap@entry=0xffffb5013ded7c58) at ../../../../kern/subr_prf.c:336 > #2 0xffffffff8062f5b1 in panic (fmt=fmt@entry=0xffffffff80925ce0 "trap") at ../../../../kern/subr_prf.c:255 > #3 0xffffffff80222fa7 in trap (frame=0xffffb5013ded7da0) at ../../../../arch/amd64/amd64/trap.c:324 > #4 0xffffffff8021c3b5 in alltraps () > #5 0xffffffff8101d617 in ?? () > #6 0xffffffff8024515f in sy_call (rval=0xffffb5013ded7eb0, uap=0xffffb5013ded7f00, l=0xffff93e59a2d8ae0, sy=0xffffffff80c35410 <sysent+8592>) at ../../../../sys/syscallvar.h:65 > #7 sy_invoke (code=358, rval=0xffffb5013ded7eb0, uap=0xffffb5013ded7f00, l=0xffff93e59a2d8ae0, sy=0xffffffff80c35410 <sysent+8592>) at ../../../../sys/syscallvar.h:94 /* syscall: "compat_90_fstatvfs1" ret: "int" args: "int" "struct statvfs90 *" "int" */ #define SYS_compat_90_fstatvfs1 358 Is/was your compat90 module loaded into the kernel? Is there some missing dependency for compat90 to load the module before using it. > #8 syscall (frame=0xffffb5013ded7f00) at ../../../../arch/x86/x86/syscall.c:138 > #9 0xffffffff802086ad in handle_syscall () > (gdb) thread apply all bt > > Thread 2.1 (<kvm>): > #0 0xffffffff8022130a in ?? () > #1 0xffffb5013ded73cc in ?? () > #2 0x0000000000000104 in ?? () > #3 0xffffffff80925ce0 in ?? () > #4 0xffffb5013ded7c58 in ?? () > #5 0xffffb5013ded7c40 in ?? () > #6 0xffffffff8062f500 in ?? () > #7 0xffffb50100000000 in ?? () > #8 0xffff93e59a2d8ae0 in ?? () > #9 0x0000000000000006 in ?? () > #10 0xffffb5013ded7da0 in ?? () > #11 0xffffb5013ded7ca0 in ?? () > #12 0xffffffff8062f5b1 in ?? () > #13 0xffffb5013ded7ca0 in ?? () > #14 0xffffffff00000008 in ?? () > #15 0xffffb5013ded7cb0 in ?? () > #16 0xffffb5013ded7c70 in ?? () > #17 0xffffb5013ded7e98 in ?? () > #18 0xffffb5013ded7da0 in ?? () > #19 0xffffb5013ded7da0 in ?? () > #20 0x0000000000000000 in ?? () > > > (aside: Why don't repeated commands in gdb generate the same output?) > > Just FYI - debugging shifting sands... > > > Cheers, > > Patrick >
Attachment:
signature.asc
Description: OpenPGP digital signature