Date: Tue, 20 Oct 2020 11:55:30 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Johnston <markj@freebsd.org> Cc: mmel@freebsd.org, freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 Message-ID: <20201020185530.GA69476@www.zefox.net> In-Reply-To: <20201020163005.GD46122@raichu> References: <20201006021029.GA13260@www.zefox.net> <20201006133743.GA96285@raichu> <c8a5e1d2-0c47-e3f7-300a-f2fce55d2819@freebsd.org> <20201019203954.GC46122@raichu> <20201019230909.GA66675@www.zefox.net> <20201020163005.GD46122@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 20, 2020 at 12:30:05PM -0400, Mark Johnston wrote: > > I set up a RPi3 to try and repro this and have so far managed to trigger > it once using Peter Holm's stress2 suite, so I'll keep investigating. I > hadn't configured a dump device, but I was able to confirm from DDB that > PCPU_GET(curpmap) == &vmspace0->vm_pmap. > Is the invalid pmap fault related in any way to intensity of swap usage? That's easily adjusted using -j values building things like www/chromium. In the past, when I've reported crashes caused by stress2 I've observed a "that's inevitable" sort of response with some regularity. Panics when doing more normal things like make seem to stimulate greater interest. > For future reference, > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html The pieces are all in place, but the machine doesn't seem to find core dumps when coming up after a crash. It does routinely issue "no core dumps found" during reboot, so it's looking. It it necessary to issue a dump command from inside the debugger? Thanks for writing! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201020185530.GA69476>