Date: Sun, 20 Jan 2019 16:32:55 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: RPI3 clang crashes in buildworld Message-ID: <D9D33537-9BCE-4DFB-A646-6069A5C00BDB@yahoo.com> In-Reply-To: <20190120234707.GA39449@www.zefox.net> References: <20190120163236.GA34653@www.zefox.net> <C94A2A62-B199-49C4-9DC2-C41714B10D62@yahoo.com> <20190120234707.GA39449@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Jan-20, at 15:47, bob prohaska <fbsd at www.zefox.net> wrote: > On Sun, Jan 20, 2019 at 01:39:04PM -0800, Mark Millard wrote: >> On 2019-Jan-20, at 08:32, bob prohaska <fbsd at www.zefox.net> wrote: >>=20 >>=20 >>> Has anyone had recent success running buildworld on an RPI3? I'm = seeing >>> signal 11's with increasing regularity during the building libraries = phase. >>> Two months ago -j4 buildworld ran successfully. >>>=20 >>> It's possible my system is corrupted. I've tinkered with a kernel = patch at >>> = https://people.freebsd.org/~gonzo/arm/patches/vchiq-wip-20180217.diff >>> back when the system was at r342781, but the patch was reversed and = the >>> machine is now up to r343165 using "clean start" buildworld without = -j >>> and careful restarts, deleting the last .o file before the crashes. >>>=20 >>> There are no hardware errors on the console and only clang is = crashing. >>> The machine will even run the chromium browser without crashing, but = it >>> does grumble: >>>=20 >>> bob@www:~ % chrome >>> = [83827:1218383872:0120/075747.927080:ERROR:gpu_process_transport_factory.c= c(1016)] Lost UI shared context. >>> = [84111:1339003392:0120/075753.574384:ERROR:command_buffer_proxy_impl.cc(11= 3)] ContextResult::kFatalFailure: Shared memory handle is not valid=20 >>>=20 >>> The most recent buildworld steps were=20 >>> svnlite up /usr/src >>> make cleandir (twice) >>> rm -rf /usr/obj/usr/ >>> make kernel-toolchain >>> make buildkernel >>> make installkernel >>> (reboot) >>> make buildworld (using -DNO_CLEAN for restarts) >>>=20 >>> Have I taken all the steps possible for a clean rebuild? >>>=20 >>> At the moment both buildworld and chromium are running, without=20 >>> any additional problems. >>=20 >>=20 >> You may want to give more details, such as the content of . . . >>=20 >> /etc/make.conf >> /etc/src.conf >> *.meta files for the failed commands (if any) >>=20 >> Listing some example *.meta file information from a cross build >> (not likely problem files): >>=20 >> # cd /usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/bin/sh >> # ls -lTdrt *.meta >> . . . >> -rw-r--r-- 1 root wheel 4236 Dec 11 23:42:04 2018 nodes.o.meta >> -rw-r--r-- 1 root wheel 3603 Dec 11 23:42:05 2018 sh.full.meta >> -rw-r--r-- 1 root wheel 726 Dec 11 23:42:05 2018 sh.debug.meta >> -rw-r--r-- 1 root wheel 739 Dec 11 23:42:05 2018 sh.meta >>=20 >=20 > All are absent. /etc/src.conf and /etc/make.conf have been used in the > past but subsequently renamed to inactivate them. Good to know. > Using > find /usr/obj -name \*.meta -depth -print=20 > reports nothing, did I botch the wildcard escape?=20 > Note that this is arm64, not armv7, does that matter? The build attempt itself creates the *.meta files when WITH_META_MODE=3D is in use. But I forgot that WITH_META_MODE is not enabled by default. WITH_META_MODE has to be supplies via an environment variable style of definition if used: QUOTE The environment of make(1) for the build can be controlled via the SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some examples that may only be set in this file are WITH_DIRDEPS_BUILD, = and WITH_META_MODE, and MAKEOBJDIRPREFIX as they are environment-only variables. END QUOTE It can be supplied as a prefix on the make command line. For example I = use in a script file (/bin/sh notation): env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.amd64-hos= t" \ WITH_META_MODE=3Dyes \ WORLD_FLAGS=3D"${WORLD_FLAGS} UBLDR_LOADADDR=3D0x42000000" \ MAKEOBJDIRPREFIX=3D"/usr/obj/armv7_clang/arm.armv7" \ make $* (Not that you need all of the env value specifications above or the $* notation on a direct command on the command line.) As to why you might want such a WITH_META_MODE build: QUOTE WITH_META_MODE . . . . . . These meta files track the command that was executed, its output, and the current = directory. The filemon(4) module is required unless NO_FILEMON is = defined. . . . The meta files can also be useful for debugging. The build hides commands that are executed unless NO_SILENT = is defined. Errors cause make(1) to show some of its = environment for further debugging. . . . This must be set in the environment, make command line, or /etc/src-env.conf, not /etc/src.conf. END QUOTE The quotes are from "man src.conf". WITH_META_MODE is designed to give incremental builds once the initial META_MODE build has been = established. > The system seems to do most of its crashing when making .pico files. > It's been building libraries for a couple of hours, if past=20 > experience is any guide it'll finish in a couple of days. Getting the the records in *.meta files would require starting a new from-scratch build using WITH_META_MODE. I warn that WITH_META_MODE=3Dno would also enable the mode: the issue is if WITH_META_MODE is defined vs. not, instead of being the specific = value assigned. One thing that can help with avoiding excessive memory use is: LDFLAGS.lld+=3D -Wl,--no-threads in order to avoid ncpu+2 threads going in parallel during a specific link, so 4+2 in your context for one link. If more than one link runs at once it ends up being nlinksatonce*(4+2) threads at the same time. So for -j4 it could end up with 4*6=3D=3D24 threads at once (and I've seen such things). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D9D33537-9BCE-4DFB-A646-6069A5C00BDB>