Re: panic: pmap active 0xfffff8002d2ae9f8

On 8/18/2014 3:41 AM, Konstantin Belousov wrote:
> 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.
> 

Ok. I'll add in a larger dedicated dump device to cover the memory size
blocking debugging my recent panics.

-- 
Regards,
Bryan Drewery