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