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 0xf8002d2ae9f8 >>>> cpuid = 5 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>> 0xfe183958a7d0 >>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe183958a880 >>>> vpanic() at vpanic+0x126/frame 0xfe183958a8c0 >>>> kassert_panic() at kassert_panic+0x139/frame 0xfe183958a930 >>>> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe183958aa20 >>>> vmspace_exit() at vmspace_exit+0xa1/frame 0xfe183958aa60 >>>> exit1() at exit1+0x541/frame 0xfe183958aad0 >>>> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe183958aae0 >>>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfe183958abf0 >>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe183958abf0 >>>> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp - >>>> 0x7ffe3e8, rbp = 0x7e400 >>>> 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 0xf80035f422f8 >>>> cpuid = 10 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>> 0xfe124852b7d0 >>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124852b880 >>>> vpanic() at vpanic+0x126/frame 0xfe124852b8c0 >>>> kassert_panic() at kassert_panic+0x139/frame 0xfe124852b930 >>>> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe124852ba20 >>>> vmspace_exit() at vmspace_exit+0x9c/frame 0xfe124852ba60 >>>> exit1() at exit1+0x541/frame 0xfe124852bad0 >>>> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe124852bae0 >>>> ia32_syscall() at ia32_syscall+0x270/frame 0xfe124852bbf0 >>>> Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe124852bbf0 >>>> --- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x297e386f, rsp = >>>> 0xd7ac, rbp = 0xd7b8 --- >>>> 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 0xf8113c3c6d78 >> cpuid = 10 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe1248acc7d0 >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1248acc880 >> vpanic() at vpanic+0x126/frame 0xfe1248acc8c0 >> kassert_panic() at kassert_panic+0x139/frame 0xfe1248acc930 >> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe1248acca20 >> vmspace_exit() at vmspace_exit+0x9c/frame 0xfe1248acca60 >> exit1() at exit1+0x541/frame 0xfe1248accad0 >> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe1248accae0 >> amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1248accbf0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1248accbf0 >> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x80387fadc, rsp = >> 0x7fffd4e8, rbp = 0x7fffd5a0 --- >> 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 signature.asc Description: OpenPGP digital signature
Re: panic: pmap active 0xfffff8002d2ae9f8
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 0xf8002d2ae9f8 > >> cpuid = 5 > >> KDB: stack backtrace: > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >> 0xfe183958a7d0 > >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe183958a880 > >> vpanic() at vpanic+0x126/frame 0xfe183958a8c0 > >> kassert_panic() at kassert_panic+0x139/frame 0xfe183958a930 > >> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe183958aa20 > >> vmspace_exit() at vmspace_exit+0xa1/frame 0xfe183958aa60 > >> exit1() at exit1+0x541/frame 0xfe183958aad0 > >> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe183958aae0 > >> amd64_syscall() at amd64_syscall+0x25a/frame 0xfe183958abf0 > >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe183958abf0 > >> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp - > >> 0x7ffe3e8, rbp = 0x7e400 > >> 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 0xf80035f422f8 > >> cpuid = 10 > >> KDB: stack backtrace: > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >> 0xfe124852b7d0 > >> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124852b880 > >> vpanic() at vpanic+0x126/frame 0xfe124852b8c0 > >> kassert_panic() at kassert_panic+0x139/frame 0xfe124852b930 > >> pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe124852ba20 > >> vmspace_exit() at vmspace_exit+0x9c/frame 0xfe124852ba60 > >> exit1() at exit1+0x541/frame 0xfe124852bad0 > >> sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe124852bae0 > >> ia32_syscall() at ia32_syscall+0x270/frame 0xfe124852bbf0 > >> Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe124852bbf0 > >> --- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x297e386f, rsp = > >> 0xd7ac, rbp = 0xd7b8 --- > >> 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 0xf8113c3c6d78 > cpuid = 10 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe1248acc7d0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1248acc880 > vpanic() at vpanic+0x126/frame 0xfe1248acc8c0 > kassert_panic() at kassert_panic+0x139/frame 0xfe1248acc930 > pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe1248acca20 > vmspace_exit() at vmspace_exit+0x9c/frame 0xfe1248acca60 > exit1() at exit1+0x541/frame 0xfe1248accad0 > sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe1248accae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1248accbf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1248accbf0 > --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x80387fadc, rsp = > 0x7fffd4e8, rbp = 0x7fffd5a0 --- > 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. pgpV6mYjeYg0S.pgp Description: PGP signature
Re: panic: pmap active 0xfffff8002d2ae9f8
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 0xf8002d2ae9f8 cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe183958a7d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe183958a880 vpanic() at vpanic+0x126/frame 0xfe183958a8c0 kassert_panic() at kassert_panic+0x139/frame 0xfe183958a930 pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe183958aa20 vmspace_exit() at vmspace_exit+0xa1/frame 0xfe183958aa60 exit1() at exit1+0x541/frame 0xfe183958aad0 sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe183958aae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe183958abf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe183958abf0 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp - 0x7ffe3e8, rbp = 0x7e400 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 0xf80035f422f8 cpuid = 10 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe124852b7d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124852b880 vpanic() at vpanic+0x126/frame 0xfe124852b8c0 kassert_panic() at kassert_panic+0x139/frame 0xfe124852b930 pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe124852ba20 vmspace_exit() at vmspace_exit+0x9c/frame 0xfe124852ba60 exit1() at exit1+0x541/frame 0xfe124852bad0 sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe124852bae0 ia32_syscall() at ia32_syscall+0x270/frame 0xfe124852bbf0 Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe124852bbf0 --- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x297e386f, rsp = 0xd7ac, rbp = 0xd7b8 --- 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 0xf8113c3c6d78 cpuid = 10 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1248acc7d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1248acc880 vpanic() at vpanic+0x126/frame 0xfe1248acc8c0 kassert_panic() at kassert_panic+0x139/frame 0xfe1248acc930 pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe1248acca20 vmspace_exit() at vmspace_exit+0x9c/frame 0xfe1248acca60 exit1() at exit1+0x541/frame 0xfe1248accad0 sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe1248accae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1248accbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1248accbf0 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x80387fadc, rsp = 0x7fffd4e8, rbp = 0x7fffd5a0 --- 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 -- Regards, Bryan Drewery ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: pmap active 0xfffff8002d2ae9f8
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 0xf8002d2ae9f8 > cpuid = 5 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe183958a7d0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe183958a880 > vpanic() at vpanic+0x126/frame 0xfe183958a8c0 > kassert_panic() at kassert_panic+0x139/frame 0xfe183958a930 > pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe183958aa20 > vmspace_exit() at vmspace_exit+0xa1/frame 0xfe183958aa60 > exit1() at exit1+0x541/frame 0xfe183958aad0 > sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe183958aae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfe183958abf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe183958abf0 > --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp - > 0x7ffe3e8, rbp = 0x7e400 > 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 0xf80035f422f8 > cpuid = 10 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe124852b7d0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124852b880 > vpanic() at vpanic+0x126/frame 0xfe124852b8c0 > kassert_panic() at kassert_panic+0x139/frame 0xfe124852b930 > pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe124852ba20 > vmspace_exit() at vmspace_exit+0x9c/frame 0xfe124852ba60 > exit1() at exit1+0x541/frame 0xfe124852bad0 > sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe124852bae0 > ia32_syscall() at ia32_syscall+0x270/frame 0xfe124852bbf0 > Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe124852bbf0 > --- syscall (1, FreeBSD ELF32, sys_sys_exit), rip = 0x297e386f, rsp = > 0xd7ac, rbp = 0xd7b8 --- > 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 -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
panic: pmap active 0xfffff8002d2ae9f8
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 0xf8002d2ae9f8 cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe183958a7d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe183958a880 vpanic() at vpanic+0x126/frame 0xfe183958a8c0 kassert_panic() at kassert_panic+0x139/frame 0xfe183958a930 pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe183958aa20 vmspace_exit() at vmspace_exit+0xa1/frame 0xfe183958aa60 exit1() at exit1+0x541/frame 0xfe183958aad0 sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe183958aae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe183958abf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe183958abf0 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp - 0x7ffe3e8, rbp = 0x7e400 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
