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 much to my surprise it b
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] loa
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 somethin
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 ch
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 p
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 unexp
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 to randomdev to poll for
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'l
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 fairly low-quality report,
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 reasons that still escape me,
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
11 matches
Mail list logo
