Re: Consistent crash of BeagleBone kernel

> On Aug 8, 2015, at 11:47 PM, Konstantin Belousov <kostikbel_at_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) _at_ /Users/tim/projects/crochet/src-head/sys/kern/vfs_bio.c:3191
>> 2nd 0xc2e69400 dirhash (dirhash) _at_ /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) _at_ /Users/tim/projects/crochet/src-head/sys/kern/kern_linker.c:1030
>> 2nd 0xc2d63c94 ufs (ufs) _at_ /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 _at_ /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 _at_ /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