Date: Sun, 27 Dec 2020 22:10:18 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) Message-ID: <F9CB3890-5E07-46C9-AC40-D968F8B51B1F@yahoo.com> In-Reply-To: <20201228044840.GA28380@www.zefox.net> References: <20201228044840.GA28380@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Dec-27, at 20:48, bob prohaska <fbsd@www.zefox.net> wrote: > Having a bit of trouble migrating to stable/12 from 13.0-CURRENT=20 > FreeBSD 13.0-CURRENT #3 r368820: Sat Dec 26 19:01:50 PST 2020 =20 > bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM arm >=20 > This is on a Pi2B v1.1 The MMCCAM kernel option was added for sake=20 > of the experiment and hasn't, up to now, been accompanied by any > visible problems. World and kernel have been built many times, no > problems.=20 >=20 > Buildworld keeps stopping at > --- clang.full --- > c++ -O -pipe -fno-common -mlong-calls = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm = -I/usr/freebsd-src/contrib/llvm-project/clang/include = -I/usr/freebsd-src/lib/clang/include = -I/usr/freebsd-src/contrib/llvm-project/llvm/include = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -DHAVE_VCS_VERSION_INC -DNDEBUG = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv7-unknown-freebsd12.2-gnueabihf\" = -DLLVM_HOST_TRIPLE=3D\"armv7-unknown-freebsd12.2\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/freebsd-src/arm.armv7/tmp\" = -DLLVM_TARGET_ENABLE_ARM = -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeARMAsmParser = -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeARMAsmPrinter = -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeARMDisassembler = -DLLVM_NATIVE_TARGET=3DLLVMInitializeARMTarget = -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeARMTargetInfo = -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeARMTargetMC -ffunction-sections = -fdata-sections -gline-tables-only -Wno-for > mat-zero-length -Qunused-arguments = -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/include = -fno-exceptions -fno-rtti -std=3Dc++14 -stdlib=3Dlibc++ = -Wno-c++11-extensions -Wl,--gc-sections -static = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/lib -o clang.full = cc1_main.o cc1as_main.o cc1gen_reproducer_main.o driver.o = /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang/libcla= ng.a = /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm/libllvm= .a -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libz -lz = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libexecinfo = -lexecinfo -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libelf = -lelf = -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/ncurses/ncursesw = -lncursesw -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libthr = -lpthread -legacy > ld: error: failed to open clang.full: Cannot allocate memory > c++: error: linker command failed with exit code 1 (use -v to see = invocation) > *** [clang.full] Error code 1 >=20 > make[4]: stopped in /usr/freebsd-src/usr.bin/clang/clang > 1 error >=20 > The failure occurs many minutes after the log entry appears.=20 > No errors on the console, swap tops near half a gig. The=20 > stable/12 sources being compiled were obtained via git. The=20 > -current sources used to compile the running system were=20 > obtained using svnlite.=20 >=20 > I don't recall seeing this much swap used before by armv7,=20 > but that's the only notable oddity. =20 >=20 > The stable/12 sources have been updated every day for the=20 > past few in hopes the trouble might go away, the -current=20 > sources seem to be updated as far as svnlite goes.=20 >=20 > Any suggestions appreciated, thanks for reading >=20 I presume the historical system tuning for small memory systems from our past investigations and help that we got. You do not mention -j4 vs. -j1 or the like. I'm assuming -j1 has been tried. You have not said if you have adjusted the likes of: kern.maxswapzone or VM_SWZONE_SIZE_MAX or if you get the boot notices about the likes of: warning: total configured swap (??? pages) exceeds maximum recommended = amount (??? pages). Mistuning these could lead to RAM fragmentation issues as I understand. Since the allocation failure is reported by ld while it tries to produce clang.full , I wonder if you have used: LDFLAGS.lld+=3D -Wl,--no-threads in, say, /etc/make.conf ? If not, the llvm ld will try to use all 4 RPi2 v1.1 cores (via threads, not via processes) and, from what I've seen, will end up trying to use more RAM than when it runs single-threaded (main thread only). Of course, links then take longer to complete. (LLVM ld actually ends up up with 4+2 threads, counting the processes's main thread as well.) Except on the machines with plenty of RAM (by a large margin for the hardware-thread count), I use --no-threads for contexts where I can readily control such. (Ports do not use LDFLAGS.lld and gnu's linker does not tolerate --no-threads as a command line option. So "readily" is limited to buildkernel and buildworld .) =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?F9CB3890-5E07-46C9-AC40-D968F8B51B1F>