Signal 11 on RPI2 running 12.0-CURRENT #6 r320526

[Mark Millard]

[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