Date: Fri, 3 Aug 2018 23:27:02 -0500 From: Kyle Evans <kevans@freebsd.org> To: Eitan Adler <lists@eitanadler.com> Cc: Konstantin Belousov <kib@freebsd.org>, freebsd-current Current <freebsd-current@freebsd.org> Subject: Re: panic: mutex pmap not owned at ... efirt_machdep.c:255 Message-ID: <CACNAnaFv9Gj%2BM2Gb8FbwY5q56dnTR6OgjZ5qth9gjr8LreHeow@mail.gmail.com> In-Reply-To: <CAF6rxg=4OnHEJa1OnJerMeEKD66nZg3j-H-XZ-9YAA1TE_NoDQ@mail.gmail.com> References: <CAF6rxg=4OnHEJa1OnJerMeEKD66nZg3j-H-XZ-9YAA1TE_NoDQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler <lists@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaFv9Gj%2BM2Gb8FbwY5q56dnTR6OgjZ5qth9gjr8LreHeow>