From owner-freebsd-arm@freebsd.org Mon Dec 28 06:10:24 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CBA764D1AE9 for ; Mon, 28 Dec 2020 06:10:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D46bg2HT4z4ktp for ; Mon, 28 Dec 2020 06:10:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1609135820; bh=GH6WgooNMb7SdPMxWGyhiNsYgBNE+h9F5gl+RHJInXr=; h=Subject:From:Date:To:From:Subject; b=KFEdXlSWdTDSBkW4QY7o94jg1B1ptTGKwtXXiCmJOAFRwBLbijaE3wmxwjN+5SAayHWSVggZHfVxUMg8V/CBmHWkzxYQ2FbF2OTjTRmtUzUI5kqg6SBt8RLlStHvkQ5JAFbWBataaA9vgCfcuvuuk2XmZAXa5upEWAeBPcrzMz9AMOMGG9xCwSyDyjduBV0LmM200YWuFrB5ApuVFUYncbKsbatPgFFeypR57NjmZk6qJFPSvbRVsDTrjtot7MaeVraMBnCEMKtbEFkzr1FKgyMO+audM3CjYH8kwPdtQGrW4GoA7Ni0iIZ600P3HMGGBwAlIncb7LM+RTdEZYO3CA== X-YMail-OSG: pmCGSoYVM1k7qnw4Ycy9oF6sWJglADnFGbwFrV4cvM.mp3Sc3KxXQr01fCVQIxZ MwsLimvLyrojEKveKSNMv2DOVGDol2qwZER_eCbpxXjfj5LHdXTvPYGi4gTav6__TtyGfAfDM74z uOIRssoA_dkRMswVrccaGPdhEuHMt1HWU3EcKhJvGv_Sq2TFEVLQZ1X2JUGqoSM8lQtd58otj4O8 ClLFlY1H4jHkxEIl5xeShiyj8mojMJWHIhfAgdAecNBKsSr.A6z82cR0.4cY2yg1xHhU4ENegb72 KRVf3JLZDTxtqWeb4Pl_qJ4Y9fWypb4NdmLNsM0pcS.BI43lB43uyU6Iv1OZBHNyYi.t7iYOd.Em KRe19oFmd80BrGTkZvE9IyQmssvYXRrZq7BJWzXL947TvD_61RuNiJgaqhRvNGqvZF3LjH9sUinG KWjMUFgI4FbEXMQ.xpD0QEF47A07IlZ6pfH_UEDCaQX3viWp2U5.NK43z_7UWkL2Xu3kdygumIQK BWPUPy0ExTQSLGomSAo1o5v4qEr0vCHSqTMBJYisIVrWsdgZYIQAyOm4SQPA7tsR.I6tp92U9v1r Ydg4iYMCLiyfmrnqxXwvqcIw2dp1Jcm4.tQ5D5qfwev2SK5kFRD_cExl.6lbuPUWmBLcO5yQaSAL MKSxN3DiTo16bRHQOV4xZm8X0zow7gSC.zytNbHzUCZToSppbYp_R83z.qPrZa5pWvMVCCYxAb5n FYaWt8dCjyvbmSyQ0jIVbQP7jPTG35rvDxHCK95USS37Xi8HkLIK2BXIlV9YmZJuF1Gb8qxZCAXh NfjxiUb_IGU39U4VmUWYo5vUvHN72PFnpM1upDSTWRysjn6F6XIRgTMZnQpKJVmRM7eAzTaHaxQh 1yOklJnMVYw_rPTWQT_.cJ.6.BCAIhHEUT4mwV4y3yX9eydmSSru8cl4ZAtONmq3TKpd5wXEdO91 JLY5YeyRaXbpALYE1ULjr8_HHDnqIUvWv16bFKO7ItamKImBOyyHafqF7ipbo7gBK1ZrXiMeL8Sr l.MiKFc.25zPKbMuhG02LtU.MaGOhG8iwnHIxRAgtCHW9rF2y7sLplVDwmm9JEfGrGlWLq2PvQP2 xk8W9lkvp08YxDKXDW3Wo99q0bf2f31v6R.aRM4ILMIK2dVBor_1gS8.MKd4c7Y22V3NgeSiMzsd r_w8MfjZAQ5vsiyD79ovctvc2ksY02WJ8W1pGrH2HpNDj6auPX2uzTM5Y6M3fftcieWzDdnJRbYk oZcJeqVaaTQWE.8jRczyH1k5jqB.P4gaAmiX2DCjSkCrCDq0Ts9vNCvM2tM5zkfheFR0UP8Rgzwj l.cGGiFdfF8TYfn16eGbqfXuJN_iVnrrcGGSQ3tOlw3Y1ueUpuuVtjnjOK8nWWc0Nqc21WRMJJz1 FKEqL9nSYKwIv6uXZ1P85lnzgRatVfsOPsCbBbUR_MD_3VmHHJWaoYweaBRcTcIKO2k5wcxGeiRW 3VQ1iNuT.3s_BcRPZj0C1nOutEH3I0KKSYrdrmMiJKs5r5T5SnEpCzSmh5TEOh5V1ZNgigyUt1zk DI_e5eloMVRLQ08dG9rDeF2qc_kRXguf3x1T91dIZaBNqauQyp3DG.SNjBVilacPgLz7qYFClpkd ktZdUsLQyZprpCW9KqfCHFc0syoDww6bff3igTkc8iFgYWK3CFTFVmnd_SBoqGh5AgnhUgT9Lb5I KIzxgrMsa6_NtBD8bs3EIOaebgTp1FcH.Qy9litgeF3ThW.7E8d_l_iIgR12MH2NN0Pr7pzPIaIK .pcD79zLAYHtNafJA8VdS8GQF1MrThiL3M.MEQyuNok38_6hm2ou_Pe_AgjW36oEsPK0ZyLFgD.7 yGeoP1Ba12mzzgmgxf241VuwT5nrMoZIysBITQyKUBFd3fVjIMFUZznNYkR.J91.kQ0NU_SlBMLe 6_lWfgsMdqwS4PtY_t1iUDk6a6HYLhfA.gfBjye2Z1FVEsu_ibQE0pyEqW6C7BsQHx_cUngyP7xI P3HzsU6t30frFXPqKdgnTu8Zle1PCGN8X83IINgom005pL3z0SjAxao9bYHNVlGLvtRlqZ.UJR8u JGe42v8mCksgh8Zd617HoRsbDzgjjGhFtLDIlrUkzkXUMCNIJblcHgGZENfpC77RTVbYXBi3gc5g sGqhL_nL.Pabdw36yo.jh76LSELB4i9EXPv5IruIEsZtASQjt0r09IjxEvtFYJNaNrSRJ8B_zHM. _sEJ3yEVbvx04_DXGSKtGXUqcFeVi6AX2w7JJ4WOv2Gb.NkTxSo1fs85kGZnocZA5lIiW4RF9r5O iPO6hvWSKGMmoM5JrS3fMIt9ZzJo_ZPy3L0WR7zS__nCK0LAT9LDT5_nHyOEl1fEHgnQH8Xr8x1P 94h3yUoToS5z34uyM6OYo9DFTvN.gPQ.Pqo350wkMFE1JcgzsFYDSmQLdbOW8YCU97ePqeSBdPBN UAWUqK7T09u3bZkHdpJGxBrIFqYkotopkk2Gpj2hOg7.L7c1cb8wgf0TIQgA3kNfTDRNyvIiCt1I nxpr8CQ5XFemj9GtLJQsmUIuo9khe Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 28 Dec 2020 06:10:20 +0000 Received: by smtp425.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3fd931de8ae1fc2bad7f3bace5ee0501; Mon, 28 Dec 2020 06:10:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Migrating from -current to stable/12 on RPI2B (ARMv7) From: Mark Millard In-Reply-To: <20201228044840.GA28380@www.zefox.net> Date: Sun, 27 Dec 2020 22:10:18 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201228044840.GA28380@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4D46bg2HT4z4ktp X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.146:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.146:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2020 06:10:24 -0000 On 2020-Dec-27, at 20:48, bob prohaska 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)