Re: panic: pmap active 0xfffff8002d2ae9f8

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Mon, 18 Aug 2014 11:41:42 +0300
On Fri, Aug 15, 2014 at 10:38:25PM -0500, Bryan Drewery wrote:
> On 2014-08-13 10:38, Bryan Drewery wrote:
> > On 6/24/2014 4:28 PM, Craig Rodrigues wrote:
> >> Hi,
> >> 
> >> I have a system running CURRENT at r266925 from May 31.
> >> 
> >> While doing some software builds using poudriere, the system
> >> panicked.  Unfortunately this system was not configured with
> >> swap space, so I cannot do a kernel dump.
> >> 
> >> The system is currently at the ddb prompt.
> >> Here is the backtrace:
> >> 
> >> 
> >> Here is the backtrace from ddb:
> >> 
> >> panic: pmap active 0xfffff8002d2ae9f8
> >> cpuid = 5
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> >> 0xfffffe183958a7d0
> >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe183958a880
> >> vpanic() at vpanic+0x126/frame 0xfffffe183958a8c0
> >> kassert_panic() at kassert_panic+0x139/frame 0xfffffe183958a930
> >> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfffffe183958aa20
> >> vmspace_exit() at vmspace_exit+0xa1/frame 0xfffffe183958aa60
> >> exit1() at exit1+0x541/frame 0xfffffe183958aad0
> >> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfffffe183958aae0
> >> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe183958abf0
> >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe183958abf0
> >> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp -
> >> 0x7ffffffe3e8, rbp = 0x7ffffffffe400
> >> KDB: enter: panic
> >> [ thread pid 94762 tid 101570 ]
> >> Stopped at       kdb_enter+0x3e: movq        $0.kdb_why
> >> db>
> >> 
> >> 
> >> Is this a known problem?
> >> Are there other commands I should type at the ddb prompt?
> >> --
> >> Craig
> > 
> > I have run into this as well on r269147:
> > 
> >> panic: pmap active 0xfffff80035f422f8
> >> cpuid = 10
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> >> 0xfffffe124852b7d0
> >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe124852b880
> >> vpanic() at vpanic+0x126/frame 0xfffffe124852b8c0
> >> kassert_panic() at kassert_panic+0x139/frame 0xfffffe124852b930
> >> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfffffe124852ba20
> >> vmspace_exit() at vmspace_exit+0x9c/frame 0xfffffe124852ba60
> >> exit1() at exit1+0x541/frame 0xfffffe124852bad0
> >> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfffffe124852bae0
> >> ia32_syscall() at ia32_syscall+0x270/frame 0xfffffe124852bbf0
> >> Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfffffe124852bbf0
> >> --- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x297e386f, rsp = 
> >> 0xffffd7ac, rbp = 0xffffd7b8 ---
> >> KDB: enter: panic
> >> [ thread pid 85335 tid 101517 ]
> >> Stopped at      kdb_enter+0x3e: movq    $0,kdb_why
> >> db> call doadump
> >> 
> >> Dump failed. Partition too small.
> >> = 0
> 
> Got it again on recent r269950 while building with poudriere:
> 
> panic: pmap active 0xfffff8113c3c6d78
> cpuid = 10
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> 0xfffffe1248acc7d0
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe1248acc880
> vpanic() at vpanic+0x126/frame 0xfffffe1248acc8c0
> kassert_panic() at kassert_panic+0x139/frame 0xfffffe1248acc930
> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfffffe1248acca20
> vmspace_exit() at vmspace_exit+0x9c/frame 0xfffffe1248acca60
> exit1() at exit1+0x541/frame 0xfffffe1248accad0
> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfffffe1248accae0
> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1248accbf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1248accbf0
> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x80387fadc, rsp = 
> 0x7fffffffd4e8, rbp = 0x7fffffffd5a0 ---
> KDB: enter: panic
> [ thread pid 84433 tid 101503 ]
> Stopped at      kdb_enter+0x3e: movq    $0,kdb_why
> db> call doadump
> 
> Dump failed. Partition too small.
> = 0

The interesting information is pmap->pm_active, for pmap address reported
by the panic.  Easiest way to get the active mask is using kgdb on vmcore.

Received on Mon Aug 18 2014 - 06:41:53 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC