From owner-freebsd-arm@FreeBSD.ORG Sat Sep 21 18:35:11 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D167B15 for ; Sat, 21 Sep 2013 18:35:11 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2CFDB21A0 for ; Sat, 21 Sep 2013 18:35:10 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r8LIZ6GN003137; Sat, 21 Sep 2013 18:35:06 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id y2nevyjxmug26nj3q38y9n7kke; Sat, 21 Sep 2013 18:35:06 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: freebsd on beaglebone black, lock reversal panic shortly after first boot From: Tim Kientzle In-Reply-To: Date: Sat, 21 Sep 2013 11:35:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: <23F2AC2E-E8C2-4C2E-8E0E-4F1A31DDA6FA@kientzle.com> References: To: David Cheney X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm@freebsd.org, Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 18:35:11 -0000 On Sep 21, 2013, at 2:53 AM, David Cheney 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