Date: Sun, 25 Mar 2018 10:22:06 +1100 From: Andrew Reilly <areilly@bigpond.net.au> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD Current <current@freebsd.org> Subject: Re: 12-Current panics on boot (didn't a week ago.) Message-ID: <20180324232206.GA2457@Zen.ac-r.nu> In-Reply-To: <B70A5BB4-CC2B-4503-8998-2A360D24E0CF@bigpond.net.au> References: <20180324035653.GA3411@Zen.ac-r.nu> <CANCZdfozmyxC5MuNS8Tu_LD1bbAYNTnTcPe52-6sz9KPCQou_Q@mail.gmail.com> <B70A5BB4-CC2B-4503-8998-2A360D24E0CF@bigpond.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180324232206.GA2457>