Date: Sun, 25 Mar 2018 04:35:31 +0000 From: Jonathan Looney <jonlooney@gmail.com> To: Andrew Reilly <areilly@bigpond.net.au> Cc: FreeBSD Current <current@freebsd.org>, Warner Losh <imp@bsdimp.com>, jtl@freebsd.org Subject: Re: 12-Current panics on boot (didn't a week ago.) Message-ID: <CADrOrmstNpFFK%2BoobR5yWELSmTz4_C_CV1JYiVRMpDwZ6cr_yw@mail.gmail.com> In-Reply-To: <20180325032110.GA10881@Zen.ac-r.nu> References: <20180324035653.GA3411@Zen.ac-r.nu> <CANCZdfozmyxC5MuNS8Tu_LD1bbAYNTnTcPe52-6sz9KPCQou_Q@mail.gmail.com> <B70A5BB4-CC2B-4503-8998-2A360D24E0CF@bigpond.net.au> <20180324232206.GA2457@Zen.ac-r.nu> <CANCZdfovA1MiWhp6ueSaWTCtKv31wHW6B5-pS2rCLmspDuHeTw@mail.gmail.com> <20180325032110.GA10881@Zen.ac-r.nu>
next in thread | previous in thread | raw e-mail | index | archive | help
For now, you can update through r331485 and then take TCP_BLACKBOX out of your kernel config file. That won=E2=80=99t really =E2=80=9Cfix=E2=80=9D an= ything, but should at least get you a booting system (assuming the new code from r331347 is really triggering a problem). I=E2=80=99ll take another look to see if I missed something in the commit. = But, at the moment, I=E2=80=99m hard-pressed to see how r331347 would cause the pro= blem you describe. Jonathan On Sat, Mar 24, 2018 at 9:17 PM Andrew Reilly <areilly@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 <areilly@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 ever= y > 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 > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADrOrmstNpFFK%2BoobR5yWELSmTz4_C_CV1JYiVRMpDwZ6cr_yw>