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 something in the commit. But, at
the moment, I’m hard-pressed to see how r331347 would cause the problem you
describe.


Jonathan

On Sat, Mar 24, 2018 at 9:17 PM Andrew Reilly <arei...@bigpond.net.au>
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 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 05:23:18PM -0600, Warner Losh wrote:
> > 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 <arei...@bigpond.net.au>
> > 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 signals every
> so
> > > often, as a defence against very large reads.  That wouldn't have
> > > introduced a race somewhere,
> > > or left things in an unexpected state, perhaps?  That change (r331070)
> by
> > > cem@ is just a few revisions after the one that is working for me.
> I'll
> > > start looking there...
> > >
> > > Cheers,
> > >
> > > Andrew
> > >
> > > On Sun, Mar 25, 2018 at 07:49:17AM +1100, Andrew Reilly wrote:
> > > > 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
> > >
>
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to