Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
> On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov <kostikbel_at_gmail.com> wrote:
> > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
> >> On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler <lists_at_eitanadler.com> wrote:
> >> > Hi all,
> >> >
> >> > After installing the latest current kernel I get the following panic:
> >> >
> >> > panic: mutex pmap not owned at ... efirt_machdep.c:255
> >> > cpuid =3
> >> > time = 1
> >> > ...
> >> > mtx_assert()
> >> > efi_arch_enter()
> >> > efirt_modevents()
> >> > module_register_init()
> >> > mi_startup()
> >> > btext()
> >> >
> >>
> >> This seems odd- pmap lock is acquired at [1], then asserted shortly
> >> later at [2]... I avoid some of this stuff as well as I can, but is it
> >> actually possible for PCPU_GET(...) acquired curpmap to not match
> >> curthread->td_proc->p_vmspace->vm_pmap in this context?
> >>
> >> [1] https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt.c?view=markup#l260
> >> [2] https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efirt_machdep.c?view=markup#l254
> > There could be that curpcpu not yet synced with proc0 pmap.  It could be
> > fixed.
> >
> 
> He now gets a little further, but ends up with the same panic due to
> efirtc_probe trying to get time to verify the rtc's actually
> implemented. What kind of approach must we take to ensure curcpu is
> synced?

It does not panic for me, when I load efirt.ko from the loader prompt.
Anyway, try this

diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 572b2197453..f84f56b98e2 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
_at__at_ -2655,7 +2655,7 _at__at_ pmap_pinit0(pmap_t pmap)
 			__pcpu[i].pc_ucr3 = PMAP_NO_CR3;
 		}
 	}
-	PCPU_SET(curpmap, kernel_pmap);
+	PCPU_SET(curpmap, pmap);
 	pmap_activate(curthread);
 	CPU_FILL(&kernel_pmap->pm_active);
 }