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

[Konstantin Belousov]

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.

But it is not clear to me why efi_arch_enter() is called there.  I see
the check for GetTime belonging to the range described by a map descriptor.
I do not see why do you need an enter into the EFI context for comparing
integers.