Signal 11 on RPI2 running 12.0-CURRENT #6 r320526

[Mark Millard]

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).



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