Date: Mon, 13 Jan 2020 15:40:29 +0100 From: Ralf Wenk <iz-rpi03@hs-karlsruhe.de> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: panic: non-current pmap on RPI3 on CURRENT (GENERIC) #4 r356366 Message-ID: <E1ir0tK-0057Z2-4N@smtp.hs-karlsruhe.de> In-Reply-To: <20200109115123.GZ23031@kib.kiev.ua> References: <20200108235630.GA17485@www.zefox.net> <20200109115123.GZ23031@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On 2020-01-09 at 13:51 +0200 Konstantin Belousov wrote:
> 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
> [...]
> > db>
While doing "mergemaster -F -m /usr/src" one of my RPi3s experienced
the same kind of panic:
panic: non-current pmap 0xfffffd0001bca2a0
cpuid = 1
time = 1578921150
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
pc = 0xffff000000736b3c lr = 0xffff000000106814
sp = 0xffff00005a1782b0 fp = 0xffff00005a1784c0
db_trace_self_wrapper() at vpanic+0x18c
pc = 0xffff000000106814 lr = 0xffff000000408600
sp = 0xffff00005a1784d0 fp = 0xffff00005a178580
vpanic() at panic+0x44
pc = 0xffff000000408600 lr = 0xffff0000004083b0
sp = 0xffff00005a178590 fp = 0xffff00005a178610
panic() at pmap_remove_pages+0x8b4
pc = 0xffff0000004083b0 lr = 0xffff00000074d890
sp = 0xffff00005a178620 fp = 0xffff00005a1786e0
pmap_remove_pages() at vmspace_exit+0xc0
pc = 0xffff00000074d890 lr = 0xffff0000006d3710
sp = 0xffff00005a1786f0 fp = 0xffff00005a178720
vmspace_exit() at exit1+0x4f8
pc = 0xffff0000006d3710 lr = 0xffff0000003c2ab4
sp = 0xffff00005a178730 fp = 0xffff00005a1787a0
exit1() at sys_sys_exit+0x10
pc = 0xffff0000003c2ab4 lr = 0xffff0000003c25b8
sp = 0xffff00005a1787b0 fp = 0xffff00005a1787b0
sys_sys_exit() at do_el0_sync+0x514
pc = 0xffff0000003c25b8 lr = 0xffff000000753c44
sp = 0xffff00005a1787c0 fp = 0xffff00005a178860
do_el0_sync() at handle_el0_sync+0x90
pc = 0xffff000000753c44 lr = 0xffff000000739224
sp = 0xffff00005a178870 fp = 0xffff00005a178980
handle_el0_sync() at 0x403ef6bc
pc = 0xffff000000739224 lr = 0x00000000403ef6bc
sp = 0xffff00005a178990 fp = 0x0000ffffffffd7c0
KDB: enter: panic
[ thread pid 44425 tid 100460 ]
Stopped at 0x4040ddfc
db>
db> bt
Tracing pid 44425 tid 100460 td 0xfffffd000fff5560
db_trace_self() at db_stack_trace+0xf8
pc = 0xffff000000736b3c lr = 0xffff000000103c58
sp = 0xffff00005a177e80 fp = 0xffff00005a177eb0
db_stack_trace() at db_command+0x228
pc = 0xffff000000103c58 lr = 0xffff0000001038d0
sp = 0xffff00005a177ec0 fp = 0xffff00005a177fa0
db_command() at db_command_loop+0x58
pc = 0xffff0000001038d0 lr = 0xffff000000103678
sp = 0xffff00005a177fb0 fp = 0xffff00005a177fd0
db_command_loop() at db_trap+0xf4
pc = 0xffff000000103678 lr = 0xffff00000010697c
sp = 0xffff00005a177fe0 fp = 0xffff00005a178200
db_trap() at kdb_trap+0x1d8
pc = 0xffff00000010697c lr = 0xffff00000044fa74
sp = 0xffff00005a178210 fp = 0xffff00005a1782c0
kdb_trap() at do_el1h_sync+0xf4
pc = 0xffff00000044fa74 lr = 0xffff0000007535b8
sp = 0xffff00005a1782d0 fp = 0xffff00005a178300
do_el1h_sync() at handle_el1h_sync+0x78
pc = 0xffff0000007535b8 lr = 0xffff000000739078
sp = 0xffff00005a178310 fp = 0xffff00005a178420
handle_el1h_sync() at kdb_enter+0x34
pc = 0xffff000000739078 lr = 0xffff00000044f0c0
sp = 0xffff00005a178430 fp = 0xffff00005a1784c0
kdb_enter() at vpanic+0x1a8
pc = 0xffff00000044f0c0 lr = 0xffff00000040861c
sp = 0xffff00005a1784d0 fp = 0xffff00005a178580
vpanic() at panic+0x44
pc = 0xffff00000040861c lr = 0xffff0000004083b0
sp = 0xffff00005a178590 fp = 0xffff00005a178610
panic() at pmap_remove_pages+0x8b4
pc = 0xffff0000004083b0 lr = 0xffff00000074d890
sp = 0xffff00005a178620 fp = 0xffff00005a1786e0
pmap_remove_pages() at vmspace_exit+0xc0
pc = 0xffff00000074d890 lr = 0xffff0000006d3710
sp = 0xffff00005a1786f0 fp = 0xffff00005a178720
vmspace_exit() at exit1+0x4f8
pc = 0xffff0000006d3710 lr = 0xffff0000003c2ab4
sp = 0xffff00005a178730 fp = 0xffff00005a1787a0
exit1() at sys_sys_exit+0x10
pc = 0xffff0000003c2ab4 lr = 0xffff0000003c25b8
sp = 0xffff00005a1787b0 fp = 0xffff00005a1787b0
sys_sys_exit() at do_el0_sync+0x514
pc = 0xffff0000003c25b8 lr = 0xffff000000753c44
sp = 0xffff00005a1787c0 fp = 0xffff00005a178860
do_el0_sync() at handle_el0_sync+0x90
pc = 0xffff000000753c44 lr = 0xffff000000739224
sp = 0xffff00005a178870 fp = 0xffff00005a178980
handle_el0_sync() at 0x403ef6bc
pc = 0xffff000000739224 lr = 0x00000000403ef6bc
sp = 0xffff00005a178990 fp = 0x0000ffffffffd7c0
db>
db> show pcpu
cpuid = 1
dynamic pcpu = 0x3fea1f00
curthread = 0xfffffd000fff5560: pid 44425 tid 100460 critnest 1 "install"
curpcb = 0xffff00005a178aa0
fpcurthread = 0xfffffd000fff5560: pid 44425 "install"
idlethread = 0xfffffd0000aaa560: tid 100004 "idle: cpu1"
curvnet = 0
spin locks held:
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.
I do not know the exact kernel debugger commands to print/show the
"curcpu pc_curpmap content" or dump "*(struct pmap *)0xfffffd0001bca2a0"
and "*pc_curpmap" to help, but this RPi3 can stay in the kernel debugger
for a while.
If you can tell me the neccessary kernel debugger commands I will execute
them and mail the results.
As there is no swap-space configured, I think I am unable to procude a
kernel coredump which could be analysed later.
The panic happend during an update to a CURRENT of today, but I saved
former state in a boot environment.
Ralf
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1ir0tK-0057Z2-4N>