Date: Mon, 11 May 2015 10:08:22 +0200 From: Johan Schuijt-Li <johan@300.nl> To: Bryan Drewery <bdrewery@FreeBSD.org> Cc: freebsd-stable@freebsd.org Subject: Re: panic: pmap active 0xfffff8001b7154b8 Message-ID: <1DEF14DA-341D-4C96-A166-5E187565CECE@300.nl> In-Reply-To: <554B7F5D.3050805@FreeBSD.org> References: <C8964592-7239-4988-AA80-D3634143A5C4@300.nl> <554B7F5D.3050805@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Small update for archiving purposes: I=E2=80=99ve been in contact with bdrewery and kib outside of the = mailing list which resulted in the following patch: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D282679 = <https://svnweb.freebsd.org/base?view=3Drevision&revision=3D282679>; We=E2=80=99re currently in the process of testing this patch and we=E2=80=99= re cautiously positive on the results thus far. We=E2=80=99ll 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: >=20 > On 5/7/2015 7:08 AM, Johan Schuijt-Li wrote: >> Hi, >>=20 >> We=E2=80=99ve 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=E2=80=99ve switched to = running a kernel with INVARIANTS enabled. This resulted for us in the = following panic: >>=20 >> Unread portion of the kernel message buffer: >> panic: pmap active 0xfffff8001b7154b8 >> cpuid =3D 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 =3D 0x80158af1a, rsp = =3D 0x7fffffffac38, rbp =3D 0x7fffffffad40 --- >>=20 >>=20 >> I=E2=80=99ve 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= >> >>=20 >=20 > 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. >=20 >> Are other people aware of this issue or working on this? >>=20 >> I can provide access to a VM with a kernel dump and the kernel build = for extra information if needed. >>=20 >=20 > What we really need is a full core dump (minidump) and backtrace. This > will let us inspect the pmap state. >=20 > = 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.h= tml = <https://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.= html> >=20 >=20 > --=20 > Regards, > Bryan Drewery
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1DEF14DA-341D-4C96-A166-5E187565CECE>