Date: Sun, 2 Jul 2017 14:34:36 -0700 From: Mark Millard <markmi@dsl-only.net> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Signal 11 on RPI2 running 12.0-CURRENT #6 r320526 Message-ID: <38241DC9-8A8D-4B90-A678-5A4F7511029B@dsl-only.net> In-Reply-To: <1AAA5539-C81F-407E-8310-8F446665E7FC@dsl-only.net> References: <20170702015517.GA14839@www.zefox.net> <FB279B4E-8804-498D-AB36-6D0143C35E45@dsl-only.net> <20170702203651.GA17014@www.zefox.net> <1AAA5539-C81F-407E-8310-8F446665E7FC@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[Fixing some poor wording.] On 2017-Jul-2, at 2:28 PM, Mark Millard <markmi at dsl-only.net> wrote: > On 2017-Jul-2, at 1:36 PM, bob prohaska <fbsd at www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38241DC9-8A8D-4B90-A678-5A4F7511029B>