Date: Sun, 9 Aug 2015 10:53:20 -0700 From: Tim Kientzle <tim@kientzle.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Consistent crash of BeagleBone kernel Message-ID: <350C3412-910F-4B08-A903-A51D18474DAF@kientzle.com> In-Reply-To: <20150809064704.GH2072@kib.kiev.ua> References: <CC793A5E-83D2-4169-AECB-9690572A00D0@kientzle.com> <20150809064704.GH2072@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Aug 8, 2015, at 11:47 PM, Konstantin Belousov <kostikbel@gmail.com> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?350C3412-910F-4B08-A903-A51D18474DAF>