From nobody Tue Jan 25 21:23:51 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DF7151986F20 for ; Tue, 25 Jan 2022 21:24:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4Jk0GZ4jVDz4sSR for ; Tue, 25 Jan 2022 21:24:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643145837; bh=zDwfMWNYC3xnGCkKfUW52ANzBBKsmYKwVS4x4MkTCGI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=eXF7RfrrHPPIDm6B+yOqWNaT84vQGbkiaOmX0Sn1OeKxZUaDHJ87296Fe7AJTAaq+dPMto77J6M9D43V114Nlpnl1LoDZ/zTVw6RbNpAXo53Giz4/cvXy2UT7cXz5mTzIt5tuwJK1h7zDkGiADV6H7e4OB+7i7tUz8LzDvGBJh4TSNdSXPl1EXHS73ri8IuO3CHHc6H0nxhhmpUtU1CEZtjq+xVNdeoDatCOdNE2t+jS3+cm42GKiBOAa3hoUA8GCPWryqpO19/SmvBBlGDMXAGHJNZSaX7qvz1RZ5J3nzVCYiZKanKS1/ERyW2q8qpxmoKzy6FpL78sC8JPlii/Pg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643145837; bh=1lib6Lj9Z8GIO+sbCrC5/s+eDFsftguLDbs1uosRrYH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=je50Q60Topz65NupNXPhIZ4Qi1IhJ3oT9sp9hqKBiHNmVSqYEC8sfJDlXVjUVqJEAHAAV76NL+hEEi1ngQ4wTVl/BeTWNtG4x8CERTceosRIOKN2dOf6oXKdCQGNUnukJNgGplbOtlU8tsdIGl1dFs0F8XOqDK6NEE9hF7zZNzcpUQYj6xDh8b6yQTxg3j/K3rrb7BaotH1Hh3Xbpk6rVha+HmNN66TncQCUAvx/mIe9tzOApRU/31rsYv7rBgpT/USnmtjGwthyQVvRgZUj8ayD1xmho6Ypxqv89OWlJs7QatSrQx7aXZsn0KZ2yz+pccyCxYlfvQwNHPH/U4pYXw== X-YMail-OSG: eqrukj4VM1nEGs6RxLQ1PgmCfZxKnE5WTQ9PHW4Vp6IPB54Z3L9LDUPDH84lN3T eA54s1QMz_Rz1VFRaFY1RMB6AUAdFfh80ctMwIdC2yo4X8yF4OqJTYVLr8IsZ2yjESIHcCdydGVZ VtYGarLdCISR2YZ6f2Z2P4rZxIHqhqYgnfz6mSC9ubvZO.RN8YMOb1ctGPcIcv3wBzWPOGhInmIv OMeD1Rm6vjYhwWseWeqGm7lM2mXtbilnAHQBhRlJWwVZaQRzbp3I1yXOUGTYI4u8I3_VpAbHkfvr 3LAlbwD0sMOBKyFpArJtK7tVw9_1tnAEINg8MrnvCRb2B5nOgMrn9nnXg82hG._1KeEXVtoDniKZ oqO8yb8N2F4sDydIniddCFeno.IxL5oalUPu.ZE8J.ihk3CKf5OGVt6m0zuD.1ZkJZexD9OV3hLR eTBrZRnOs3MnaZdkIFHrRd2.0U6LPCwBNsdgtTKT_MFpJolJHYmNQUeK_wjTv_h7.GN7e2uk8LT0 ksLNOU0EuPj.I12U1RcZMrN8l47c70Hvo_GTOsNS9rWd76NDu_sMkpmZTsSrtGyFAcFIhNj.o5mC 7P6GJHAMKoaHPkjASSwvGAQ12Pd4KK4GsWhOdPT7uBO35Se6g0H2ldOJljsTl2.iLoBH3X5HMy4d 7Rak66Ebb7dci1OkTW_EY_RMqJBV39pakW4hT0E7xO4JhrxZAkDqXtSM6x7TakaR2x6JVabhnwk9 zyQDAZO2hJflU45Uf5bdJkmFEA_mA_WhS7dbyKvjvb1s0Pw5Sjw2zbSHeIRFyHiuWcIIrBlGZgay qkACyBi2Y8B6m_DJRVJgi6HLvrSMyc4TZAwJRyNBkJSvEmaFAnaZ4u...QRGdXRR3DKPx7LDlAnP cM42EyAYq94uO8srBGKgLZfsuUNc0mR9gdmt7kKv6476pDT.fiXOEZ25MRdCAva5QuJF6uuu2ywk jfEIGkejQGxmECAe_KeN85aH.CBaV6mKTSzyGoPLUdVoBpdQy_OHGakaye_L7ZeVKf208HUOny8B dVnuPPcg.YGL03sGr1dMsRqHtrAGWYwFhxHTFMzPuOL4anm_dWqOYxN7XXKx355VWUSHvSos0QEz Jqq1ESl2yT4kIrv_9L0W17UgppXMmyQJDxNUZi1UN04gh5SJo_5iOUbp6gflrHntPGGmp7CiHFfY Oa7AhXYoL9rGR4v8tggiDk04r466Ep7PmbelXefa9R1sF15VRLoH8iQAQeouGJZcI2Uh0zwQcEkf T9b3MeCxdEoF_3biimzzxnga6Kc7XD0pdj_Ju07AwqwU3dYdjNww9ubDoRYtnbzM160fgGube8iB o5I9W605QFuVNhJSZChQl.qTLKpP6qU7qtFJOHqI815hhgFdNwumfS3iOIG9dy4IcAbfeNnOWcbx 9bIFYB6vZ5KGGOSEYj4O9wZCfD6FYoc0tqWYHtUOBX7WsU1CysASd.1B1BqFF1RBMpQ9E8ibXc.t Z5Sm0j_LWyX1txMZkB81nKNIsRALVMqVAsh871ySgvWGcKQC1kUBzV8BTaHBC9mKkRBBfQ42t6jA yvpQx5lP44ot0O9Ymnk0C3Zu4bf2EL8SQUHoRbITAr1LfJh3XQQe8osQF.M7sPbfuqCutZjGq_fK 8siLV9ff6lkZkZ.W0tIKPeb0WCG0M.FOirYmWmzMNdVDsTZ9a6igpgAP4g8nEfFcDX3rOBO0IzHP DksyBcQ4OqFGyGufSTQpjXyI5IIyHvz.k5GEArScu8LWzCuPV5BKJxft3LknBvgi6e2C3Li.anXr llFocsxZ.juHZA78c3YiwXrCVrOuzmnVrz407yUzeoZ5oKWITJlyM6SHP5WThiTy69fIIB0hUyIk qxsdqK8_nQ0ZNvO6b4snMNvUD8LYPA6VRnAhaM3Kz3Vrq.EL0U_w8SbZC9UWV.l2dzvY3KjnrjZJ otyZ.a.7EUAh.c6gcPgdhdyylpIzjZAVUPKpUUGq5U4NXlHql3yzktJvaiSKMI5Bb4fvDQdJ9tkx 63Hv0LBjOsJohCwGe2pwzYb61d0la.LLLUqw9FY4WBCuu5yPiK5PtZNZUWfO6QyZAYkgfhfWH_UY CS3rs.Q_RTW7SM3fEA1WPZqvWUVP3xlM5Vdp0M0FrXo7UkCoRWPigvuwqve75dx8sBmAewtXxxPu lcMldCBzBgUp84r5HoNtLkw9dP3hO6oRuU0Ec.RCmiTuzzRDQD1ZKRCAkp7Rz7GJWx2zi1lRDLv1 GLF3cr67U6ip69wzOKufN.BUrRTBkz63e81US58sJxSfbmN1c6.56P_Utth3ehzFhz.qyg17lGY2 yrmRlLYb69CYdSeM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 25 Jan 2022 21:23:57 +0000 Received: by kubenode521.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1f543b14c039aa99f9cef7e632c4589a; Tue, 25 Jan 2022 21:23:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13 From: Mark Millard In-Reply-To: <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> Date: Tue, 25 Jan 2022 13:23:51 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <47B71886-ADDD-43C4-A0E0-0DB066E3E9D2@yahoo.com> References: <20220121031601.GA26308@www.zefox.net> <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jk0GZ4jVDz4sSR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=eXF7Rfrr; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com 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]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-25, at 12:49, Mark Millard wrote: > On 2022-Jan-25, at 10:08, bob prohaska wrote: >=20 >> On Tue, Jan 25, 2022 at 09:13:08AM -0800, Mark Millard wrote: >>>=20 >>> -DBATCH ? I'm not aware of there being any use of that symbol. >>> Do you have a documentation reference for it so that I could >>> read about it? >>>=20 >> It's a switch to turn off dialog4ports. I can't find the reference >> now. Perhaps it's been deprecated? A name like -DUSE_DEFAULTS would >> be easier to understand anyway.=20 >=20 > I've never had buildworld buildkernel or the like try to use > dialog4ports. I've only had port building use it. buildworld > and buildkernel can be done with no ports installed at all. > dialog4ports is a port. >=20 > I think -DBATCH was ignored for the activity at hand. Actual evidence for my claim: # grep -r "\" /usr/main-src/Makefile* /usr/main-src/share/mk/ | = more # grep -r "\" /usr/main-src/Makefile* /usr/ports/Mk/ | more /usr/ports/Mk/bsd.licenses.mk:.if ${_LICENSE_STATUS} =3D=3D "ask" && = defined(BATCH) /usr/ports/Mk/bsd.licenses.mk:IGNORE=3D License ${_LICENSE} = needs confirmation, but BATCH is defined /usr/ports/Mk/Uses/perl5.mk:. if defined(BATCH) && = !defined(IS_INTERACTIVE) /usr/ports/Mk/Uses/perl5.mk:. endif # defined(BATCH) && = !defined(IS_INTERACTIVE) /usr/ports/Mk/Uses/cmake.mk:# Default: not set, unless = BATCH or PACKAGE_BUILDING is defined /usr/ports/Mk/Uses/cmake.mk:.if defined(BATCH) || = defined(PACKAGE_BUILDING) /usr/ports/Mk/bsd.port.mk:# to skip this = port by setting ${BATCH}, or compiling only /usr/ports/Mk/bsd.port.mk:.if defined(BATCH) /usr/ports/Mk/bsd.port.mk:.if defined(BATCH) /usr/ports/Mk/bsd.port.mk:SCRIPTS_ENV+=3D BATCH=3Dyes /usr/ports/Mk/bsd.port.mk:# If we're in BATCH mode and the port is = interactive, or we're /usr/ports/Mk/bsd.port.mk:# one might want to leave a build in BATCH = mode running /usr/ports/Mk/bsd.port.mk:.if (defined(IS_INTERACTIVE) && = defined(BATCH)) /usr/ports/Mk/bsd.port.mk: defined(PACKAGE_BUILDING) || = defined(BATCH)) >> On a whim, I tried building devel/llvm13 on a Pi4 running -current = with=20 >> 8 GB of RAM and 8 GB of swap. To my surprise, that stopped with: >> nemesis.zefox.com kernel log messages: >> +FreeBSD 14.0-CURRENT #26 main-5025e85013: Sun Jan 23 17:25:31 PST = 2022 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1873450, size: = 4096 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 521393, size: = 4096 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 209826, size: = 12288 >> +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1717218, size: = 24576 >> +pid 56508 (c++), jid 0, uid 0, was killed: failed to reclaim memory >>=20 >> On an 8GB machine, that seems strange.=20 >=20 > -j build? -j4 ? >=20 > Were you watching the swap usage in top (or some such)? >=20 > Note: The "was killed" related notices have been improved > in main, but there is a misnomer case about "out of swap" > (last I checked). >=20 > An environment that gets "swap_pager: indefinite wait buffer" > notices is problematical and the I/O delays for the virtual > memory subsystem can lead to kills, if I understand right. >=20 > But, if I remember right, the actual message for a directly > I/O related kill is now different. >=20 > I think that being able to reproduce this case could be > important. I probably can not because I'd not get the > "swap_pager: indefinite wait buffer" in my hardware > context. >=20 >> Per the failure message I restarted the build of devel/llvm13 with=20 >> make -DBATCH MAKE_JOBS_UNSAFE=3DYES > make.log & >=20 > Just like -DBATCH is for ports, not buildworld buildkernel, > MAKE_JOBS_UNSAFE=3D is for ports, not buildworld buildkernel, > at least if I understand right. >=20 > In other words, it probably would have been the same result > without the two arguments. Actual evidence for my claim for MAKE_JOBS_UNSAFE : # grep -r MAKE_JOBS_UNSAFE /usr/main-src/Makefile* = /usr/main-src/share/mk/ | more # grep -r MAKE_JOBS_UNSAFE /usr/ports/Mk/ /usr/ports/Mk/bsd.port.mk:# MAKE_JOBS_UNSAFE /usr/ports/Mk/bsd.port.mk:.if defined(DISABLE_MAKE_JOBS) || = defined(MAKE_JOBS_UNSAFE) /usr/ports/Mk/bsd.port.mk:BUILD_FAIL_MESSAGE+=3D Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer. /usr/ports/Mk/bsd.gecko.mk:.if defined(DISABLE_MAKE_JOBS) || = defined(MAKE_JOBS_UNSAFE) >> It seems to be running with only one thread so far, not sure if = that's >> by design or happenstance. >>=20 >>>> However, restarting buildworld using -j1 appears to have worked = past >>>> the former point of failure. >>>=20 >>> Hmm. That usually means one (or both) of two things was involved >>> in the failure: >>>=20 >>> A) a build race where something is not (fully) ready when >>> it is used >>>=20 >>> B) running out of resources, such as RAM+SWAP >>>=20 >>=20 >> The stable/13 machine is short of swap; it has only 2 GB, which >> used to be enough. >=20 > So RAM+SWAP is 1 GiByte + 2 GiByte, so 3 GiByte on that > RPi3*? (That would have been good to know earlier, such > as for my attempts at reproduction.) >=20 > -j for the RPi3* when it was failing? >=20 > Did you havae failures with the .cpp and .sh (so no > make use involved) in the RAM+SWAP context? >=20 >> Maybe that's the problem, but having an error=20 >> report that says it's a segfault is a confusing diagnostic.=20 >>=20 >>> But, as I understand, you were able to use a .cpp and >>> .sh file pair that had been produced to repeat the >>> problem on the RPi3B --and that would not have been a >>> parallel-activity context. >>>=20 >>=20 >> To be clear, the reproduction was on the same stable/13 that >> reported the original failure. An attempt at reproduction >> on a different Pi3 running -current ran without any errors. >> Come to think of it, that machine had more swap, too. >=20 > How much swap? >=20 >>>> It's in the building libraries phase now. >>>> Based on log size I'd guess it's about halfway through buildworld. >>>>=20 >>>=20 >>> Well, hopefully you will not be stuck with -j1 builds in >>> the future as well. >>>=20 >> Indeed! >=20 > At this point, I expect that the failure was tied to the > RAM+SWAP totaling to 3 GiBytes. >=20 > Knowing that context we might have a reproducible report > that can be made based on the .cpp and .sh files, where > restricting the RAM+SWAP use allowed is part of the > report. =3D=3D=3D Mark Millard marklmi at yahoo.com