Date: Sat, 21 Sep 2013 11:35:06 -0700 From: Tim Kientzle <tim@kientzle.com> To: David Cheney <david.cheney@canonical.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: <23F2AC2E-E8C2-4C2E-8E0E-4F1A31DDA6FA@kientzle.com> In-Reply-To: <CAHPQsETr9tXQ99atJBFyv1epE-cC9fn6EkfpC0zMt2u%2B1UkpVQ@mail.gmail.com> References: <CAHPQsES33YNYVGFF=dFLinaNQex2wrAm%2B8e6qHip1-HdaAg26Q@mail.gmail.com> <op.w3q9gg2g8527sy@212-182-167-131.ip.telfort.nl> <CAHPQsETr9tXQ99atJBFyv1epE-cC9fn6EkfpC0zMt2u%2B1UkpVQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?23F2AC2E-E8C2-4C2E-8E0E-4F1A31DDA6FA>