Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

On Tue, Oct 20, 2020 at 11:55:30AM -0700, bob prohaska wrote:
> 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.

I don't think there is any direct relation with swap usage.  The one
time I've reproduced this so far there was no swapping involved.  I've
noticed that stress2 runs on the RPi3 tend to abort or hang in various
ways, but so far haven't seen any panics except the one we're chasing.

> > 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? 

It depends: if debug.debugger_on_panic is set to 1, you will indeed need
to issue a "dump" command from DDB before rebooting.  Otherwise the
system should automatically dump and reboot.  You'll need to have
"dumpdev" configured in rc.conf in order for vmcores to be recovered
automatically.  Otherwise savecore(8) can be run manually.

> Thanks for writing!
> 
> bob prohaska
>