Re: 12-Current panics on boot (didn't a week ago.)

2018-03-31 Thread Joe Maloney
The drm-next-kmod, and drm-stable-kmod modules panic for me. I will attach logs when I can. On Friday, March 30, 2018, Andrew Reilly wrote: > Hi Jonathan, all, > > I've just compiled and booted a kernel derived from current-GENERIC > but with nooptions TCP_BLACKBOX, and

Re: 12-Current panics on boot (didn't a week ago.)

2018-03-30 Thread Andrew Reilly
Hi Jonathan, all, I've just compiled and booted a kernel derived from current-GENERIC but with nooptions TCP_BLACKBOX, and much to my surprise it boots. Possible link to network-related activities is that the next line of boot output that was not being displayed during the crash is: [ath_hal]

Re: 12-Current panics on boot (didn't a week ago.)

2018-03-25 Thread Jonathan Looney
For now, you can update through r331485 and then take TCP_BLACKBOX out of your kernel config file. That won’t really “fix” anything, but should at least get you a booting system (assuming the new code from r331347 is really triggering a problem). I’ll take another look to see if I missed

Re: 12-Current panics on boot (didn't a week ago.)

2018-03-25 Thread Herbert J. Skuhra
On Sun, 25 Mar 2018 05:21:10 +0200, Andrew Reilly wrote: > > 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

Re: 12-Current panics on boot (didn't a week ago.)

2018-03-24 Thread Andrew Reilly
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

Re: 12-Current panics on boot (didn't a week ago.)

2018-03-24 Thread Andrew Reilly
So, r331464 crashes in the same place, on my system. r331064 still boots OK. I'll keep searching. One week ago there was a change to randomdev to poll for signals every so often, as a defence against very large reads. That wouldn't have introduced a race somewhere, or left things in an

Re: 12-Current panics on boot (didn't a week ago.)

2018-03-24 Thread Warner Losh
Thanks Andrew... I can't recreate this on my VM nor my real hardware. Warner On Sat, Mar 24, 2018 at 5:22 PM, Andrew Reilly wrote: > So, r331464 crashes in the same place, on my system. r331064 still boots > OK. I'll keep searching. > > One week ago there was a change

Re: 12-Current panics on boot (didn't a week ago.)

2018-03-24 Thread Andrew Reilly
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.

Re: 12-Current panics on boot (didn't a week ago.)

2018-03-24 Thread Warner Losh
Also, what rev failed? I booted r331464 last night w/o issue. Warner On Fri, Mar 23, 2018 at 9:56 PM, Andrew Reilly 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

Re: 12-Current panics on boot (didn't a week ago.)

2018-03-24 Thread Warner Losh
That lock has been there for a long, long time (like 5 or 6 major releases)... It's surprising that it's causing issues now. Can you bisect versions to find when this starts happening? Warner On Fri, Mar 23, 2018 at 9:56 PM, Andrew Reilly wrote: > Hi all, > > For

12-Current panics on boot (didn't a week ago.)

2018-03-24 Thread Andrew Reilly
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