> On Aug 8, 2015, at 11:47 PM, Konstantin Belousov <kostik...@gmail.com> wrote: > > 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. >> >> Any suggested workarounds? >> >> Tim >> >> ==== log trace === >> ... >> 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,NET_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 >> >> 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 > > 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. > > 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’m not familiar with that code; does it use the kernel linker? Tim _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
