Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Sep 2017 11:56:55 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        Emmanuel Vadot <manu@bidouilliste.com>, freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org>
Subject:   FYI: I have submitted an intermittent -r323246 debug-kernel panic problem for the Pine64+ 2GB context (so A64): bugzilla 222234
Message-ID:  <99F9944A-E03C-45F5-8F6C-C3DD1E76D328@dsl-only.net>

next in thread | raw e-mail | index | archive | help
[Note: I've jumped from way back around -r308??? to
-r323246 finally. The -r323246 is an example but
I've no clue what range of revisions of head also
show the issue. But before this jump I'd never seen
such a boot-panic.]

The content of the description is:

Based on a head -r323246 debug kernel build:

Occasionally when I boot the Pine64+ 2GB I get:

panic: acquiring blockable sleep lock with spinlock or critical section =
held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710

This is the PMAP_LOCK in:

int
pmap_fault(pmap_t pmap, uint64_t esr, uint64_t far)
. . .

It reports:

[ thread pid 0 tid 100058 ]
Stopped at      sched_switch+0x2b8:     ldrb    w9, [x8, #894]

It turns our that x8 is reported as holding the value zero:

db> show reg
. . .
x8                           0
. . .

The back trace is:

. . . (a little text given a clue about where in the boot sequence) . . =
.
CPU  1: (null) (null) r0p0 affinity:  0
CPU  2: (null) (null) r0p0 affinity:  0
CPU  3: (null) (null) r0p0 affinity:  0
panic: acquiring blockable sleep lock with spinlock or critical section =
held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710
cpuid =3D 0
time =3D 13
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
         pc =3D 0xffff0000005efc78  lr =3D 0xffff000000088094
         sp =3D 0xffff000069850080  fp =3D 0xffff000069850290

db_trace_self_wrapper() at vpanic+0x164
         pc =3D 0xffff000000088094  lr =3D 0xffff00000031764c
         sp =3D 0xffff0000698502a0  fp =3D 0xffff000069850310

vpanic() at kassert_panic+0x15c
         pc =3D 0xffff00000031764c  lr =3D 0xffff0000003174e4
         sp =3D 0xffff000069850320  fp =3D 0xffff0000698503e0

kassert_panic() at witness_checkorder+0x160
         pc =3D 0xffff0000003174e4  lr =3D 0xffff000000374990
         sp =3D 0xffff0000698503f0  fp =3D 0xffff000069850470

witness_checkorder() at __mtx_lock_flags+0xa8
         pc =3D 0xffff000000374990  lr =3D 0xffff0000002f8b7c
         sp =3D 0xffff000069850480  fp =3D 0xffff0000698504b0

__mtx_lock_flags() at pmap_fault+0x40
         pc =3D 0xffff0000002f8b7c  lr =3D 0xffff000000606994
         sp =3D 0xffff0000698504c0  fp =3D 0xffff0000698504e0

pmap_fault() at data_abort+0xb8
         pc =3D 0xffff000000606994  lr =3D 0xffff000000608a9c
         sp =3D 0xffff0000698504f0  fp =3D 0xffff0000698505a0

data_abort() at do_el1h_sync+0xfc
         pc =3D 0xffff000000608a9c  lr =3D 0xffff0000006088f0
         sp =3D 0xffff0000698505b0  fp =3D 0xffff0000698505e0

do_el1h_sync() at handle_el1h_sync+0x74
         pc =3D 0xffff0000006088f0  lr =3D 0xffff0000005f1874
         sp =3D 0xffff0000698505f0  fp =3D 0xffff000069850700

handle_el1h_sync() at sched_switch+0x2a8
         pc =3D 0xffff0000005f1874  lr =3D 0xffff00000033f0c8
         sp =3D 0xffff000069850710  fp =3D 0xffff0000698507f0

sched_switch() at mi_switch+0x1b8
         pc =3D 0xffff00000033f0c8  lr =3D 0xffff00000032161c
         sp =3D 0xffff000069850800  fp =3D 0xffff000069850820

mi_switch() at taskqgroup_binder+0x7c
         pc =3D 0xffff00000032161c  lr =3D 0xffff00000035510c
         sp =3D 0xffff000069850830  fp =3D 0xffff000069850860

taskqgroup_binder() at gtaskqueue_run_locked+0x104
         pc =3D 0xffff00000035510c  lr =3D 0xffff000000354f74
         sp =3D 0xffff000069850870  fp =3D 0xffff0000698508e0

gtaskqueue_run_locked() at gtaskqueue_thread_loop+0x9c
         pc =3D 0xffff000000354f74  lr =3D 0xffff000000354d10
         sp =3D 0xffff0000698508f0  fp =3D 0xffff000069850910

gtaskqueue_thread_loop() at fork_exit+0x7c
         pc =3D 0xffff000000354d10  lr =3D 0xffff0000002dbd3c
         sp =3D 0xffff000069850920  fp =3D 0xffff000069850950

fork_exit() at fork_trampoline+0x10
         pc =3D 0xffff0000002dbd3c  lr =3D 0xffff000000608664
         sp =3D 0xffff000069850960  fp =3D 0x0000000000000000


See:


=
https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-September/00330=
0.html


for more details.

In the console output this seem to be about the same
place that the non-debug kernel (typically?) fails.

=3D=3D=3D
Mark Millard
markmi@dsl-only.net




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99F9944A-E03C-45F5-8F6C-C3DD1E76D328>