Hi Warner, The breakage was in 331470, and at least one version earlier, that I updated past when it panicked. I'm guessing that kdb's inability to dump would be down to it not having found any disk devices yet, right? So yes, bisecting to narrow down the issue is probably the best bet. I'll try your r331464: if that works that leaves only four or five revisions. Of course the breakage could be hardware specific. Cheers, -- Andrew On 25 March 2018 1:14:40 am AEDT, Warner Losh <imp_at_bsdimp.com> wrote: >Also, what rev failed? I booted r331464 last night w/o issue. > >Warner > >On Fri, Mar 23, 2018 at 9:56 PM, Andrew Reilly <areilly_at_bigpond.net.au> >wrote: > >> Hi all, >> >> For reasons that still escape me, I haven't been able to get a kernel >dump >> to debug, sorry. >> >> Just thought that I'd generate a fairly low-quality report, to see if >> anyone has some ideas. >> >> The last kernel that I have that booted OK (and I'm now running) is: >> FreeBSD Zen.ac-r.nu 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r331064M: >Sat >> Mar 17 07:54:51 AEDT 2018 >root_at_Zen:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >> amd64 >> >> The machine is a: >> CPU: AMD Ryzen 7 1700 Eight-Core Processor (2994.46-MHz >K8-class >> CPU) >> Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 >Stepping=1 >> Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8, >> APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> >> >> Kernels built from head as of a couple of hours ago get through >launching >> the other CPUs and then stops somewhere in random, apparently: >> >> SMP: AP CPU #2 Launched! >> Timecounter "TSC-low" frequency 1497223020 Hz quality 1000 >> random: entpanic: mtx_lock() of spin mutex (null) _at_ >> /usr/src/sys/kern/subr_bus.c:617 >> cpuid = 0 >> time = 1 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe00004507a0 >> vpanic() at vpanic+0x18d/frame 0xfffffe0000450800 >> doadump () at doadump/frame 0xfffffe0000450880 >> __mtx_lock_flags() at __mtx_lock_flags+0x163/frame 0xfffffe00004508d0 >> devctl_queue_data_f() at devctl_queue_data_f+0x6a/frame >0xfffffe0000450900 >> g_dev_taste() at g_dev_taste+0x370/frame 0xfffffe0000450a10 >> g_new_provider_event() at g_new_provider_event+0xfa/frame >> 0xfffffe0000450a30 >> g_run_events() at g_run_events+0x151/frame 0xfffffe0000450a70 >> fork_exit() at fork_exit+0x84/frame 0xfffffe0000450ab0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000450ab0 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> KDB: enter: panic >> [ thread pid 14 tid 100052 ] >> Stopped at kdb_enter+0x3b: movq $0,kdb_why >> db> dump >> Cannot dump: no dump device specified. >> db> >> >> Now dumping worked fine the last time the kernel panicked: I have >> dumpdev=AUTO in rc.conf and I have swap on nvd0p3 (first) and >> /dev/zvol/root/swap >> (second, larger than the first.) >> >> Root on the nvd0p2 is ZFS, and ther's a four-drive raidZ with user >> directories and what-not on them, and another ZFS on an external USB >drive >> that I use >> for backups, unmounted. >> >> In the new kernels, we clearly aren't even getting as far as finding >the >> hubs and controllers, let alone the drives. >> >> I've attached dmesg.boot from the last boot from last week's good >kernel. >> (While briefly in yoyo mode I turned the SMT back on, so now there >are 16 >> cores >> instead of the eight mentioned in the crash dump. Didn't help, but I >> haven't turned it back off yet.) >> >> Cheers, >> >> Andrew >> >> >> _______________________________________________ >> freebsd-current_at_freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >"freebsd-current-unsubscribe_at_freebsd.org" >> >>Received on Sat Mar 24 2018 - 20:56:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:15 UTC