FYI: I have submitted an intermittent -r323246 debug-kernel panic problem for the Pine64+ 2GB context (so A64): bugzilla 222234

[Mark Millard]

[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 = 0
time = 13
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
         pc = 0xffff0000005efc78  lr = 0xffff000000088094
         sp = 0xffff000069850080  fp = 0xffff000069850290

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


See:


https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-September/003300.html


for more details.

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

===
Mark Millard
markmi at dsl-only.net