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

From: Andrew Reilly <areilly_at_bigpond.net.au>
Date: Sun, 25 Mar 2018 14:21:10 +1100
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 <areilly_at_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_at_ 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
> >
Received on Sun Mar 25 2018 - 02:15:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:15 UTC