From owner-freebsd-arm@freebsd.org Sun Jul 2 21:34:40 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73C53DADBE9 for ; Sun, 2 Jul 2017 21:34:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 296A477A3A for ; Sun, 2 Jul 2017 21:34:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7680 invoked from network); 2 Jul 2017 21:36:09 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 2 Jul 2017 21:36:09 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sun, 02 Jul 2017 17:34:38 -0400 (EDT) Received: (qmail 16218 invoked from network); 2 Jul 2017 21:34:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jul 2017 21:34:37 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 55020EC7C08; Sun, 2 Jul 2017 14:34:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Signal 11 on RPI2 running 12.0-CURRENT #6 r320526 From: Mark Millard In-Reply-To: <1AAA5539-C81F-407E-8310-8F446665E7FC@dsl-only.net> Date: Sun, 2 Jul 2017 14:34:36 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <38241DC9-8A8D-4B90-A678-5A4F7511029B@dsl-only.net> References: <20170702015517.GA14839@www.zefox.net> <20170702203651.GA17014@www.zefox.net> <1AAA5539-C81F-407E-8310-8F446665E7FC@dsl-only.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 21:34:40 -0000 [Fixing some poor wording.] On 2017-Jul-2, at 2:28 PM, Mark Millard wrote: > On 2017-Jul-2, at 1:36 PM, bob prohaska wrote: > >>> https://lists.freebsd.org/pipermail/freebsd-current/2017-July/066471.html >>> >>> The last of those has a fix suggested by Konstantin Belousov. >>> >> >> I'm tempted to try the fix but the diff does not look compatible with >> a self hosted system. Will removing the a/ and b/ make the paths >> digestible to patch? > > A problem may be that far too many programs fail > for the original code: lots of programs are > broken. It is not clear that buildworld is > viable self-hosted for builds of -r320509 > through -r320561 for head (inclusive of both > ends). "builds *started from* -r320509 through -r320561" would have been a better wording for the purpose: The problem is that once one is running one of those things may be very messed up in that lots of programs may fail. > Head has had the code checked in since then: > -r320570 has the fix. So you can get the > source from there. > > Or patch has a -p option for stripping a prefix > from the paths it uses (by a count of /'s removed > by deleting the prefix): See man patch. > > Or copy/paste the + text lines and delete the +'s > in the first column --and delete the original lines > that are shown as - lines. The patch is small so > this should be easy to to reliably. > > > > I happen to cross build and to be able to boot > from an alternate FreeBSD with the disk in > question available to mount from there. So I > did not have to deal with fully self hosted. > > So I'm not sure what happens if one tries to > buildworld from the messed up context. I'd > not be surprised at a program-crash failure. > > > > FYI: there is a separate issue noted in > bugzilla 220404 that prevents a production > style kernel build from completing a normal > boot sequence for TARGET_ARCH=powerpc: fatal > kernel trap. The basic type of issue is > memory aliasing in a union in struct socket > being mishandled. The detailed mishandling > results likely vary from TARGET_ARCH to > TARGET_ARCH so appearing to work is an > accident but does happen. > > I've been able to boot and use a debug kernel > build on TARGET_ARCH=powerpc but again it is > likely an accident. (The machine is actually > also 64-bit capable but I use 32-bit FreeBSD > on it as well.) > > I've been able to "boot -s" (single user) > TARGET_ARCH=powerpc for a production kernel > but have had other problems in that context > that I've not described anywhere yet. As stands > I'm not sure that what I could say would be > useful to anyone: more investigation needed. > > I've been lucky in that TARGET_ARCH=powerpc64 > accidentally seems to work for this issue, > even with a production kernel. > > Also lucky that amd64 works by accident so > that I have that as my primary cross-build environment still. === Mark Millard markmi at dsl-only.net