panic: pmap active 0xfffff8001b7154b8

[Johan Schuijt-Li]

Small update for archiving purposes:

I’ve been in contact with bdrewery and kib outside of the mailing list which resulted in the following patch:
https://svnweb.freebsd.org/base?view=revision&revision=282679 <https://svnweb.freebsd.org/base?view=revision&revision=282679>

We’re currently in the process of testing this patch and we’re cautiously positive on the results thus far. We’ll be rolling out this patch further and in roughly one week we should be confident enough that this problem is fully resolved.

- Johan


> On 07 May 2015, at 17:06, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> 
> On 5/7/2015 7:08 AM, Johan Schuijt-Li wrote:
>> Hi,
>> 
>> We’ve been seeing (seemingly) random reboots on 10.1-RELEASE virtual machines (KVM virtualisation) on our production servers. In an attempt to determine what was causing this we’ve switched to running a kernel with INVARIANTS enabled. This resulted for us in the following panic:
>> 
>> Unread portion of the kernel message buffer:
>> panic: pmap active 0xfffff8001b7154b8
>> cpuid = 3
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe03dd1493a0
>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe03dd149450
>> vpanic() at vpanic+0x126/frame 0xfffffe03dd149490
>> kassert_panic() at kassert_panic+0x139/frame 0xfffffe03dd149500
>> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfffffe03dd1495f0
>> exec_new_vmspace() at exec_new_vmspace+0x16a/frame 0xfffffe03dd149650
>> exec_elf64_imgact() at exec_elf64_imgact+0x658/frame 0xfffffe03dd149720
>> kern_execve() at kern_execve+0x5e4/frame 0xfffffe03dd149a80
>> sys_execve() at sys_execve+0x37/frame 0xfffffe03dd149ae0
>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe03dd149bf0
>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe03dd149bf0
>> --- syscall (59, FreeBSD ELF64, sys_execve), rip = 0x80158af1a, rsp = 0x7fffffffac38, rbp = 0x7fffffffad40 ---
>> 
>> 
>> I’ve only come across one other report here (without result unfortunate):
>> https://lists.freebsd.org/pipermail/freebsd-current/2014-June/050827.html <https://lists.freebsd.org/pipermail/freebsd-current/2014-June/050827.html> <https://lists.freebsd.org/pipermail/freebsd-current/2014-June/050827.html <https://lists.freebsd.org/pipermail/freebsd-current/2014-June/050827.html>>
>> 
> 
> I looked around for the conclusion of that thread but could not find it.
> I was reproducing so often I'm sure this case was fixed. I may have
> privately contacted one of the VM maintainers to fix it. However lacking
> evidence I think it just stopped happening for me and I never reported
> anything useful.
> 
>> Are other people aware of this issue or working on this?
>> 
>> I can provide access to a VM with a kernel dump and the kernel build for extra information if needed.
>> 
> 
> What we really need is a full core dump (minidump) and backtrace. This
> will let us inspect the pmap state.
> 
> https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html <https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html>
> https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html <https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html>
> 
> 
> -- 
> Regards,
> Bryan Drewery