freebsd on beaglebone black, lock reversal panic shortly after first boot

[David Cheney]

Thanks to all that have replied. I've been able to build the few ports
that I need to achieve my goal of a fresh builder for our Go build
dashboard [1]. As an experiment i'm going to rebuild the image with
WITNESS disabled. I notice when building that the compilation process
is single threaded. Is there a way of passing an analog of gmake's -j2
to the build process ?

Cheers

Dave

[1] build.golang.org

On Sun, Sep 22, 2013 at 4:35 AM, Tim Kientzle <tim at kientzle.com> wrote:
>
> On Sep 21, 2013, at 2:53 AM, David Cheney <david.cheney at canonical.com> wrote:
>
>> Ronald,
>>
>> Thanks for your reply. I'm sorry, I am inexperienced with this sort of
>> thing, the machine has not crash, in fact it still building a port
>> now. From my linux background, if I saw that much output, the host
>> would be kerput.
>
> FreeBSD on BBB is running a development kernel right now.
> As a result, it has some internal check code that reports
> "possible errors" very verbosely.  Not all of the things reported
> by these checks are real problems.
>
> When FreeBSD-10 is officially released later this year we
> will have production versions of FreeBSD.  If you build
> your own FreeBSD image, you can also disable these additional
> checks.
>
> In particular, development FreeBSD kernels include a
> subsystem called "WITNESS" which verifies how the various
> parts of the kernel use locks.  WITNESS is normally not
> enabled on production kernels because the additional checks
> do slow the system down significantly.
>
> A "Lock-order reversal" (LoR) is a common problem with complex
> multi-threaded code (such as operating system kernels) which
> can *sometimes* cause the system to freeze or crash.  LoRs are
> one of several issues that WITNESS was designed to check for.
>
> In FreeBSD terminology a "panic" is a kernel crash.  On development
> kernels, this will usually drop you immediately into the kernel
> debugger.  On production kernels, a panic usually leads the system to
> immediately reboot.
>
> The two LoRs you saw here are:
>
> 1) bufwait/dirhash reversal.
>
>  lock order reversal:
> 1st 0xcd1299d0 bufwait (bufwait) @
> /root/crochet-freebsd/src/sys/kern/vfs_bio.c:3059
> 2nd 0xc2a8f600 dirhash (dirhash) @
> /root/crochet-freebsd/src/sys/ufs/ufs/ufs_dirhash.c:284
>
> 2) ufs/bufwait reversal.
>
> lock order reversal:
> 1st 0xc2c06814 ufs (ufs) @ /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099
> 2nd 0xcd1299d0 bufwait (bufwait) @
> /root/crochet-freebsd/src/sys/ufs/ffs/ffs_vnops.c:262
> 3rd 0xc2cb9154 ufs (ufs) @ /root/crochet-freebsd/src/sys/kern/vfs_subr.c:2099
>
> I believe both of these are "false positives".  They are not a real
> problem but WITNESS doesn't have quite enough context
> to know that.  If I understand correctly, filesystem locks are
> claimed in a particular order determined by the filesystem
> structure; WITNESS only knows the names of the locks,
> not what filesystem objects they refer to, so it can't really
> tell if the order is correct or not.
>
> There are a couple of other pretty common LoR false
> positives.  You'll start to recognize those pretty soon.
>
> If you see *new* LoRs, we're very interested.
>
> Tim
>