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"