Date: Sun, 22 Sep 2013 17:09:06 +1000 From: David Cheney <david.cheney@canonical.com> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@freebsd.org, Ronald Klop <ronald-freebsd8@klop.yi.org> Subject: Re: freebsd on beaglebone black, lock reversal panic shortly after first boot Message-ID: <CAHPQsEQrMSMKo0JL7Z1fHo515NxhJpKdY7nd%2BBVsUdaGL%2BbW_Q@mail.gmail.com> In-Reply-To: <23F2AC2E-E8C2-4C2E-8E0E-4F1A31DDA6FA@kientzle.com> References: <CAHPQsES33YNYVGFF=dFLinaNQex2wrAm%2B8e6qHip1-HdaAg26Q@mail.gmail.com> <op.w3q9gg2g8527sy@212-182-167-131.ip.telfort.nl> <CAHPQsETr9tXQ99atJBFyv1epE-cC9fn6EkfpC0zMt2u%2B1UkpVQ@mail.gmail.com> <23F2AC2E-E8C2-4C2E-8E0E-4F1A31DDA6FA@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@kientzle.com> wrote: > > On Sep 21, 2013, at 2:53 AM, David Cheney <david.cheney@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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHPQsEQrMSMKo0JL7Z1fHo515NxhJpKdY7nd%2BBVsUdaGL%2BbW_Q>