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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC