From owner-freebsd-arm@FreeBSD.ORG Sun Sep 22 07:09:14 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 B7AFB654 for ; Sun, 22 Sep 2013 07:09:14 +0000 (UTC) (envelope-from david.cheney@canonical.com) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42F7E2EE7 for ; Sun, 22 Sep 2013 07:09:13 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id eo20so1551298lab.6 for ; Sun, 22 Sep 2013 00:09:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RGjFeNgmLGPvzhbPVc1b/tOTxa48CRwMC6BX3Wl7rjI=; b=UWSe9JS2+iSgDDr6DRaKlUrOHdwvl/qxeFeM0UfudI0b4miFa+beSHk5uxEo6eghTN NsNHEY+sFOLhiAt78p8cOwDv3pJ2GzKaS9H7aD7tZDpqefWn6tOtRB3fDUHZfnt2Rv9/ 3JNlab6Rpw5oRlzXWELIvsMt0zUMH67kvqHg7q+VZOEWQgzQkcxcJ7gGcqgRL54bW/ky PfGVKv7VIZ0OcD9k7VyiRR016OiyqR7ePGcWK5ush3uXxZKzw0y4CZzy07rbXlwIcRaZ NHc/IF3FVR+Vcj9bO7c9cA3IrrZT5PP4vwsSpdMuB5w9OoltFHLxhWF0cGohtNcrgde2 /lbw== X-Gm-Message-State: ALoCoQlI8RxeW7x916Fa/+whe3QQ0HMq1EN8wnkw3C00HhxslTB+JJabZfU1QF+DsNDrRRioz3rd MIME-Version: 1.0 X-Received: by 10.112.29.147 with SMTP id k19mr14249033lbh.9.1379833746530; Sun, 22 Sep 2013 00:09:06 -0700 (PDT) Received: by 10.114.183.47 with HTTP; Sun, 22 Sep 2013 00:09:06 -0700 (PDT) In-Reply-To: <23F2AC2E-E8C2-4C2E-8E0E-4F1A31DDA6FA@kientzle.com> References: <23F2AC2E-E8C2-4C2E-8E0E-4F1A31DDA6FA@kientzle.com> Date: Sun, 22 Sep 2013 17:09:06 +1000 Message-ID: Subject: Re: freebsd on beaglebone black, lock reversal panic shortly after first boot From: David Cheney To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 22 Sep 2013 07:09:14 -0000 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 wrote: > > 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 >