Re: 12-Current-r331347 panics on boot (r331346 and earlier didn't.)

OK, I've completed the search: r331346 works, r331347 panics
somewhere in the initialization of random.

In the 331347 change (Add the "TCP Blackbox Recorder") I can't see
anything obvious to tweak, unfortunately.  It's a fair chunk of new
code but it's all network-stack related, and my kernel is panicking
long before any network activity happens.

Any suggestions?

Cheers,

Andrew

On Sat, Mar 24, 2018 at 08:14:40AM -0600, Warner Losh 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"
> >
> >
> _______________________________________________
> 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"