Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Sep 2017 18:41:13 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 222234] head -r323246 aarch64 (Pine64+ 2GB) boot time context, sometimes: acquiring blockable sleep lock with spinlock or critical section held
Message-ID:  <bug-222234-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222234

            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@FreeBSD.org
          Reporter: markmi@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 =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/003300=
.html

for more details.

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

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222234-8>