[Bug 222234] head -r323246 aarch64 (Pine64+ 2GB) boot time context, sometimes: acquiring blockable sleep lock with spinlock or critical section held

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Mon Sep 11 18:41:14 UTC 2017


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222234

            Bug ID: 222234
           Summary: head -r323246 aarch64 (Pine64+ 2GB) boot time context,
                    sometimes: acquiring blockable sleep lock with
                    spinlock or critical section held
           Product: Base System
           Version: CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: markmi at dsl-only.net

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:

. . .
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list