[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-arm
Subject: Re: RPI3 clang crashes in buildworld
From: Mark Millard via freebsd-arm <freebsd-arm () freebsd ! org>
Date: 2019-01-21 0:32:55
Message-ID: D9D33537-9BCE-4DFB-A646-6069A5C00BDB () yahoo ! com
[Download RAW message or body]
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:
> >
> >
> > > 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.
Good to know.
> 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 build attempt itself creates the *.meta files when WITH_META_MODE=
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="/root/src.configs/make.conf" SRCCONF="/dev/null" \
SRC_ENV_CONF="/root/src.configs/src.conf.armv7-clang-bootstrap.amd64-host" \ \
WITH_META_MODE=yes \ WORLD_FLAGS="${WORLD_FLAGS} UBLDR_LOADADDR=0x42000000" \
MAKEOBJDIRPREFIX="/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
> 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=no 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+= -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==24 threads at once
(and I've seen such things).
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
freebsd-arm@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic