[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-stable
Subject:    Re: panic: pmap active 0xfffff8001b7154b8
From:       Johan Schuijt-Li <johan () 300 ! nl>
Date:       2015-05-11 8:08:22
Message-ID: 1DEF14DA-341D-4C96-A166-5E187565CECE () 300 ! nl
[Download RAW message or body]

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@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

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


[prev in list] [next in list] [prev in thread] [next in thread]