Date: Sun, 20 Jan 2019 15:47:07 -0800 From: bob prohaska <fbsd@www.zefox.net> To: freebsd-arm@freebsd.org Subject: Re: RPI3 clang crashes in buildworld Message-ID: <20190120234707.GA39449@www.zefox.net> In-Reply-To: <C94A2A62-B199-49C4-9DC2-C41714B10D62@yahoo.com> References: <20190120163236.GA34653@www.zefox.net> <C94A2A62-B199-49C4-9DC2-C41714B10D62@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > > > 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. > > > > 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. > > > > 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: > > > > bob@www:~ % chrome > > [83827:1218383872:0120/075747.927080:ERROR:gpu_process_transport_factory.cc(1016)] Lost UI shared context. > > [84111:1339003392:0120/075753.574384:ERROR:command_buffer_proxy_impl.cc(113)] ContextResult::kFatalFailure: Shared memory handle is not valid > > > > The most recent buildworld steps were > > 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) > > > > Have I taken all the steps possible for a clean rebuild? > > > > At the moment both buildworld and chromium are running, without > > any additional problems. > > > You may want to give more details, such as the content of . . . > > /etc/make.conf > /etc/src.conf > *.meta files for the failed commands (if any) > > Listing some example *.meta file information from a cross build > (not likely problem files): > > # 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 > All are absent. /etc/src.conf and /etc/make.conf have been used in the past but subsequently renamed to inactivate them. Using find /usr/obj -name \*.meta -depth -print reports nothing, did I botch the wildcard escape? Note that this is arm64, not armv7, does that matter? 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 experience is any guide it'll finish in a couple of days. Thanks for reading, and any guidance! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190120234707.GA39449>