Date: Thu, 9 Jan 2020 13:51:23 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: panic: non-current pmap on RPI3 on CURRENT (GENERIC) #4 r356366 Message-ID: <20200109115123.GZ23031@kib.kiev.ua> In-Reply-To: <20200108235630.GA17485@www.zefox.net> References: <20200108235630.GA17485@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 08, 2020 at 03:56:30PM -0800, bob prohaska wrote: > A Pi3 running FreeBSD 13.0-CURRENT (GENERIC) #4 r356366 reported, > while compiling www/chromium: > > panic: non-current pmap 0xfffffd000385f5a0 > cpuid = 1 > time = 1578525992 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc = 0xffff000000736b9c lr = 0xffff000000106814 > sp = 0xffff00005a92ae40 fp = 0xffff00005a92b050 > > db_trace_self_wrapper() at vpanic+0x18c > pc = 0xffff000000106814 lr = 0xffff0000004088c0 > sp = 0xffff00005a92b060 fp = 0xffff00005a92b110 > > vpanic() at panic+0x44 > pc = 0xffff0000004088c0 lr = 0xffff000000408670 > sp = 0xffff00005a92b120 fp = 0xffff00005a92b1a0 > > panic() at pmap_remove_pages+0x8b4 > pc = 0xffff000000408670 lr = 0xffff00000074d890 > sp = 0xffff00005a92b1b0 fp = 0xffff00005a92b270 > > pmap_remove_pages() at exec_new_vmspace+0x188 > pc = 0xffff00000074d890 lr = 0xffff0000003c1250 > sp = 0xffff00005a92b280 fp = 0xffff00005a92b2d0 > > exec_new_vmspace() at exec_elf64_imgact+0x744 > pc = 0xffff0000003c1250 lr = 0xffff00000039a358 > sp = 0xffff00005a92b2e0 fp = 0xffff00005a92b3d0 > > exec_elf64_imgact() at kern_execve+0x458 > pc = 0xffff00000039a358 lr = 0xffff0000003c01b0 > sp = 0xffff00005a92b3e0 fp = 0xffff00005a92b730 > > kern_execve() at sys_execve+0x54 > pc = 0xffff0000003c01b0 lr = 0xffff0000003bfa2c > sp = 0xffff00005a92b740 fp = 0xffff00005a92b7b0 > > sys_execve() at do_el0_sync+0x514 > pc = 0xffff0000003bfa2c lr = 0xffff000000753c44 > sp = 0xffff00005a92b7c0 fp = 0xffff00005a92b860 > > do_el0_sync() at handle_el0_sync+0x90 > pc = 0xffff000000753c44 lr = 0xffff000000739224 > sp = 0xffff00005a92b870 fp = 0xffff00005a92b980 > > handle_el0_sync() at 0x214978 > pc = 0xffff000000739224 lr = 0x0000000000214978 > sp = 0xffff00005a92b990 fp = 0x0000ffffffffd490 > > KDB: enter: panic > [ thread pid 32060 tid 100321 ] > Stopped at 0x40425654 > db> bt > Tracing pid 32060 tid 100321 td 0xfffffd000ba68000 > db_trace_self() at db_stack_trace+0xf8 > pc = 0xffff000000736b9c lr = 0xffff000000103c58 > sp = 0xffff00005a92aa10 fp = 0xffff00005a92aa40 > > db_stack_trace() at db_command+0x228 > pc = 0xffff000000103c58 lr = 0xffff0000001038d0 > sp = 0xffff00005a92aa50 fp = 0xffff00005a92ab30 > > db_command() at db_command_loop+0x58 > pc = 0xffff0000001038d0 lr = 0xffff000000103678 > sp = 0xffff00005a92ab40 fp = 0xffff00005a92ab60 > > db_command_loop() at db_trap+0xf4 > pc = 0xffff000000103678 lr = 0xffff00000010697c > sp = 0xffff00005a92ab70 fp = 0xffff00005a92ad90 > > db_trap() at kdb_trap+0x1d8 > pc = 0xffff00000010697c lr = 0xffff00000044fd70 > sp = 0xffff00005a92ada0 fp = 0xffff00005a92ae50 > > kdb_trap() at do_el1h_sync+0xf4 > pc = 0xffff00000044fd70 lr = 0xffff0000007535b8 > sp = 0xffff00005a92ae60 fp = 0xffff00005a92ae90 > > do_el1h_sync() at handle_el1h_sync+0x78 > pc = 0xffff0000007535b8 lr = 0xffff000000739078 > sp = 0xffff00005a92aea0 fp = 0xffff00005a92afb0 > > handle_el1h_sync() at kdb_enter+0x34 > pc = 0xffff000000739078 lr = 0xffff00000044f3bc > sp = 0xffff00005a92afc0 fp = 0xffff00005a92b050 > > kdb_enter() at vpanic+0x1a8 > pc = 0xffff00000044f3bc lr = 0xffff0000004088dc > sp = 0xffff00005a92b060 fp = 0xffff00005a92b110 > > vpanic() at panic+0x44 > pc = 0xffff0000004088dc lr = 0xffff000000408670 > sp = 0xffff00005a92b120 fp = 0xffff00005a92b1a0 > > panic() at pmap_remove_pages+0x8b4 > pc = 0xffff000000408670 lr = 0xffff00000074d890 > sp = 0xffff00005a92b1b0 fp = 0xffff00005a92b270 > > pmap_remove_pages() at exec_new_vmspace+0x188 > pc = 0xffff00000074d890 lr = 0xffff0000003c1250 > sp = 0xffff00005a92b280 fp = 0xffff00005a92b2d0 > > exec_new_vmspace() at exec_elf64_imgact+0x744 > pc = 0xffff0000003c1250 lr = 0xffff00000039a358 > sp = 0xffff00005a92b2e0 fp = 0xffff00005a92b3d0 > > exec_elf64_imgact() at kern_execve+0x458 > pc = 0xffff00000039a358 lr = 0xffff0000003c01b0 > sp = 0xffff00005a92b3e0 fp = 0xffff00005a92b730 > > kern_execve() at sys_execve+0x54 > pc = 0xffff0000003c01b0 lr = 0xffff0000003bfa2c > sp = 0xffff00005a92b740 fp = 0xffff00005a92b7b0 > > sys_execve() at do_el0_sync+0x514 > pc = 0xffff0000003bfa2c lr = 0xffff000000753c44 > sp = 0xffff00005a92b7c0 fp = 0xffff00005a92b860 > > do_el0_sync() at handle_el0_sync+0x90 > pc = 0xffff000000753c44 lr = 0xffff000000739224 > sp = 0xffff00005a92b870 fp = 0xffff00005a92b980 > > handle_el0_sync() at 0x214978 > pc = 0xffff000000739224 lr = 0x0000000000214978 > sp = 0xffff00005a92b990 fp = 0x0000ffffffffd490 > > db> It would be useful to see both the curcpu pc_curpmap content, and dump both *(struct pmap *)0xfffffd000385f5a0 and *pc_curpmap from the vmcore.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200109115123.GZ23031>