panic: non-current pmap 0xffffa00020eab8f0 on Rpi3

[Mark Johnston]

On Mon, Oct 19, 2020 at 04:09:09PM -0700, bob prohaska wrote:
> On Mon, Oct 19, 2020 at 04:39:54PM -0400, Mark Johnston wrote:
> > 
> > I think vmspace_exit() should issue a release fence with the cmpset and
> > an acquire fence when handling the refcnt == 1 case, but I don't see why
> > that would make a difference here.  So, if you can test a debug patch,
> > this one will yield a bit more debug info.  If you can provide access to
> > a vmcore and kernel debug symbols, that'd be even better.
> > 
> 
> I haven't seen an invalid pmap panic since the report of October 5th.
> Your patch  applied cleanly on the Pi3 running HEAD at r366780M, 
> the M being due to patches supplied by Kyle Evans applied to 
> M       sys/arm/broadcom/bcm2835/bcm2835_mbox.c
> M       sys/arm/broadcom/bcm2835/bcm2835_sdhci.c
> M       sys/arm/broadcom/bcm2835/bcm2835_vcbus.c
> M       sys/arm/broadcom/bcm2835/bcm2835_vcbus.h
> 
> AIUI, they're something to do with DMA for peripherals. They've 
> caused no obvious trouble, if you anticipate conflicts let me know 
> and I'll remove them 

There should be no need to remove them.

> I've never seen either a vmcore file or debug symbols on this machine.
> A sequence of instructions to generate the data needed would be helpful.

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.

For future reference,
https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
has some info on configuring a dump device.  For the RPi I'm just using
a USB stick as the dump device.

> Thanks for reading!
> 
> bob prohaska
>