From owner-freebsd-current@freebsd.org Sun Aug 9 17:53:30 2015 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 389C599D502 for ; Sun, 9 Aug 2015 17:53:30 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91BB83CB for ; Sun, 9 Aug 2015 17:53:28 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id t79HrhwI009839; Sun, 9 Aug 2015 17:53:43 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.100] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id w8453ajnhvi6nmscfy6x9xbjea; Sun, 09 Aug 2015 17:53:43 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Subject: Re: Consistent crash of BeagleBone kernel From: Tim Kientzle In-Reply-To: <20150809064704.GH2072@kib.kiev.ua> Date: Sun, 9 Aug 2015 10:53:20 -0700 Cc: FreeBSD Current Message-Id: <350C3412-910F-4B08-A903-A51D18474DAF@kientzle.com> References: <20150809064704.GH2072@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.2102) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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: Sun, 09 Aug 2015 17:53:30 -0000 > On Aug 8, 2015, at 11:47 PM, Konstantin Belousov = wrote: >=20 > On Sat, Aug 08, 2015 at 05:24:37PM -0700, Tim Kientzle wrote: >> I???m seeing the following crash quite consistently on r286438. It = looks like the recent work on the kernel linker locking still has some = issues. >>=20 >> Any suggested workarounds? >>=20 >> Tim >>=20 >> =3D=3D=3D=3D log trace =3D=3D=3D >> ... >> Starting file system checks: >> /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/mmcsd0s2a: clean, 7320851 free (179 frags, 915084 blocks, 0.0% = fragmentation) >> lock order reversal: >> 1st 0xcd225040 bufwait (bufwait) @ = /Users/tim/projects/crochet/src-head/sys/kern/vfs_bio.c:3191 >> 2nd 0xc2e69400 dirhash (dirhash) @ = /Users/tim/projects/crochet/src-head/sys/ufs/ufs/ufs_dirhash.c:281 >> ??? usual stack trace omitted ... >> Mounting local file systems:random: unblocking device. >> . >> ELF ldconfig path: /lib /usr/lib /usr/lib/compat >> Setting hostname: beaglebone. >> Setting up = harvesting:[HIGH_PERFORMANCE],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NE= T_TUN,MOUSE,KEYBOARD,ATTACH,CACHED >> Feeding entropy:. >> lock order reversal: >> 1st 0xc083ef40 kernel linker (kernel linker) @ = /Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:1030 >> 2nd 0xc2d63c94 ufs (ufs) @ = /Users/tim/projects/crochet/src-head/sys/kern/vfs_lookup.c:529 >> KDB: stack backtrace: >> panic: _sx_xlock_hard: recursed on non-recursive sx kernel linker @ = /Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:552 >>=20 >> KDB: enter: panic >> [ thread pid 168 tid 100079 ] >> Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! >> db> bt >> Tracing pid 168 tid 100079 td 0xc30db6a0 >> panic: _sx_xlock_hard: recursed on non-recursive sx kernel linker @ = /Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:552 >=20 > Without a backtrace it is too much work to guess what is going on = there. > You could mark the kld_sx as recursive in kern_linker.c:linker_init(). > Then either add a hack to kern_sx.c:sx_xlock_hard() to print the > backtrace on the kld_sx recursion, or just hope that the LOR just = before > the panic is indicative. >=20 > What is strange is that this is first report of the issue, the latest = change > to kern_linker.c was around a year ago. I suspect the LOR is new. It looks like the panic is occurring when WITNESS tries to print the = backtrace for the LOR. I=E2=80=99m not familiar with that code; does it = use the kernel linker? Tim