From owner-freebsd-current@freebsd.org Mon Sep 11 18:56:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B7C6E1D5C4 for ; Mon, 11 Sep 2017 18:56:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-66.reflexion.net [208.70.210.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4AFC96DD2A for ; Mon, 11 Sep 2017 18:56:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16541 invoked from network); 11 Sep 2017 18:58:53 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Sep 2017 18:58:53 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Mon, 11 Sep 2017 14:56:57 -0400 (EDT) Received: (qmail 19537 invoked from network); 11 Sep 2017 18:56:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Sep 2017 18:56:57 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 4786CEC94BF; Mon, 11 Sep 2017 11:56:56 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) 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> Date: Mon, 11 Sep 2017 11:56:55 -0700 To: Emmanuel Vadot , freebsd-arm , FreeBSD Current , freebsd-hackers X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 18:56:58 -0000 [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