From owner-freebsd-arm@freebsd.org Sun Jul 2 21:29:00 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 B80C0DADA29 for ; Sun, 2 Jul 2017 21:29:00 +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 B8FF477714 for ; Sun, 2 Jul 2017 21:28:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28243 invoked from network); 2 Jul 2017 21:28:57 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 Jul 2017 21:28:57 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sun, 02 Jul 2017 17:28:57 -0400 (EDT) Received: (qmail 12652 invoked from network); 2 Jul 2017 21:28:56 -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:28:56 -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 45738EC7C08; Sun, 2 Jul 2017 14:28:56 -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: <20170702203651.GA17014@www.zefox.net> Date: Sun, 2 Jul 2017 14:28:55 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <1AAA5539-C81F-407E-8310-8F446665E7FC@dsl-only.net> References: <20170702015517.GA14839@www.zefox.net> <20170702203651.GA17014@www.zefox.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:29:00 -0000 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). 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