From nobody Sat Mar 05 19:22:59 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 E834219FD77B for ; Sat, 5 Mar 2022 19:46:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4K9wGF24sdz3s79 for ; Sat, 5 Mar 2022 19:46:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646509597; bh=jUyusGatyI5jxXbl7VTza3DOmL/v+I2Iavo+YiqFKrs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lIsjGbH6UL0Oi2eUlPYq0SG/VUei4inYxdybjWNl1c4svcadaoe4arz2ODSBYeNgwW/lP24AJdFqsKJa7APrHo1z/fN5kAhc4I4jPSRTtWMXVP65i4lE466oKbdCGnUVzm5Sf/2sBKfJLmdg4yce1CMBi3cmrSs9+GHm6z08mtcCs7YwRdQoX3lJqAYcmUCfl2TKowZjMvcuRbc3TOW0QOCUZEh3jzejNil/KR11CLsOQnZG/uwJST9ZrjHL7+yF3SmlU4pXPvcglFm7Qpflhg2ddi7yUJuzLHuYaFJvtecSeni9gLGrxMdZBhMF1BGl2j+jKd/Txo8x+jfWJh0qqg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646509597; bh=KQUfaWnD97l/pv5kw3Ax7LuE63Eex0X23zGZUn8TtXw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uITSjmVaGm9kRHbCkda6x+OiGZ9UX/WejQZU9/VQckqSMEJTCW/F/v9VNvtLRrSCtrEaRmw2QkYR5SXrQ42qCv3TkBLuqYkftbwqBfkXinE2Z6bVncGjtKDgw3HkPpLA5g2S/SnKW6aSLBGvFjts5Li4yS1ejl3SP88FifrNfHkHnC8+TXW6Jtxvqfet32MINxuPKFdumRfYj6FG8Cx4rH8tVlCPkQrx4yjODax59MMpMlRuB393e1kg7izVpy9RzdzW/Yci3F2idztakJJhFxgssfLIFnS2W3oQyQZnU/DFn2+qMToBYcCT6aGeAp2bjOJl1JpfPjc5fp5dU+TXrA== X-YMail-OSG: pXujB1sVM1mCFbwQ32fcAWp.eqY20waiqoxxfx4.q1KYunx5E5Wl6qlJRAU_khs w4TcJh4aJUM8qkwcpLuQPLajIZ2K.dWyWJF3Qy3TumAAlsbjSBdTKsy8DAPts55PBS57CktInZFr 3EP8LLSm7SCAivkOCw3cXN1u_5gfzaDsqOtfjmmDkGtAj4kj20QLOuu33GjVRjSGupkgGIknc902 rf.zarkaDU3FWEptKl4LeWZFrK9TUru1bycWnu5gr.MLIBnk.bZcpG6ar5dDYWKqYXaBSbvQjixD akxqkarpnWPt2NgRn3Q4v4p80Fd86nLdawTSBB_cUt28IhJa0qhn3ND2HShosiChp6gvAXx06E5Q 0VuLxlZST5rqEYK5QCBKTh9B982SLyKcryFyI2h97.m7sME3QC78mOCXPWzXFYVUo2lhOZDe25Yq 1ojZlA_ybyPsh3yyjCkWxxbif8s_DmeKtFpzb.eDTjMO8tpFCW.RSgTaNv45mKJEhFxWVnY4tgAO SlbP9OEblb7wpr7GbCiqTVZoyy9LNz9aMmECf7w.5UOgYkJJXHtHgmjJNBDZtK6OuS3arGZFREZ7 SHrYYU2ck6NL5YAB7yPR8ew9NHXARa31.i6WAcqWbgWCAmrrhnM0eKw5VFzabyd0F7yc1Gza.FjZ y5kfCP2wKh88N9TZs3RBO_P0Gu09e1wA2A9grp2MjD2unACqxedNiyRW3x6WxSHxolIZWpMZVp1v UNVFFXrFVK0nwIY48tgBpKAr2tNSTdl6Ck54Ws0usGIUKtHIhWTLNY0I91jWdsylUI3NHpPu2T8j xkuaA6ifgwIgFNcHBEjcgg8ka84yxin14qOo.qAakIiKLfH1qNfOPk1wFZFE15yFa8MOJWxtMOGw gbPiFNgZq2Px5VCml4ANks07qqd1uAgT4jpDesCbrOFB2jpLPMVxgmhc8Bzvro93gAOM4bBOrLmc oTAiluuIM.EjiW0KJNMWBKZ.TxpF5BoWs7BKMGK8l_KAureKX2gf6kSHC5kHj7Fi4XfZdZGi9qgF ZJXsH8Ni70VGEhx6gnxP60Z8BJGn8G9OYb_TH_j6.XZYKM8jkM2IztKXucaufgN5u52QZgSMg._Q ID1BdJxo4KgJZbXp0DVxqkZ.8z03UdztacfDTh1alSlPS_B0eHbwoEec6VlgttQGRSJnIiYKnOI6 Gn8xg0gNIgo7m3RtSVH69Jocv4BAZJV7bEYSvymDuKjI6150TcawdgkKUMt0lHBhcUOkuPTMiYLH F4B64l9PHdNFv2jWtT7GW3SxQWMKkEO23MRF_wxKirGr_k0W8KbRRFtxt7I3kUxNGagZQCIDupcz FmgGzZEnuEjS3j28t1nsoHyeWkoRgUJ2BV5gqVHSPzP7PMV0rs7F1k6G7GjOMTeFS3lNE.vw.PbN rdRDm95lmCtaMBgoSUliaaqJsDVfDKGyAHK4txVty.IUNCGmOr3Ak_2vDI_hLmba3_SKXDyDnMeX hqcfCR5kgo98ihoEWJupItbcjCBrBonLslXZiHJ_oYT9.OJBgxoD.pEB5PVahf_CqYiibuIGWsFl gM4_04.0uwMldXzEAHKZxwpwgCzTyC3kyvixVmJme8rvlztY9gsXem0TJDxlh0qSH2wObatrwPEa bu_DIBfNGhO.zCxhADKZ_UVc6OYTynxF6CNX3fOi_eepXsiATGJJjVfsCKm8HNiesCsFps1DM.Bk .rWQQy2AbLDHy4lCg3N4VxQz4uL21FX4BhdiSqWtDRkVl4KyA0PCFSoEJLknTMEoXSlqVRujGoTt 4RndA96whCGJPf_tLA6DvIWyQHRni.njRlyxMnt1suMGoFaoepQv6DURgDV2OaPI7g_MxuXG10Js .AJxIbJ_NXZ38kyyL4ma4uVvEN1sa2tbR5SlMnN0nt7eo6uvVxMKShyWthCFHt6Nz3SRPiMUaple 9jaytVI4jKSCrLPxSxWi4suuoXG8agsk.Nwx6WYaK0VWwMVDuS7AvEEVk9L7dSSkb7KKD3JtKh9E nv2L0u.X0ctPkiMfMTW0LVxbV0vcW1CsIz5JxXQxgHY_kVcmqL5P7GUem0dEGPkzkLFaLfjoUWvT IVnfiew57RZjdKCYwKXLW.fdm1JvEZWAJPqfhKMFCTO52l7IL3ybvp0BKL7EUwQRir1F6uHxTe4. bbXAGb6hf5GrDFbw3zbwizHk8XXHXURALiVSDFFlqInQxOockPMOurnOkA6aEqO1XdqjrnupJcyp .nANyQYeOvNSmucuDDbu_xFUBkbjNst6v3WsSPE8apAp2Ib_r6rp7cwVxdV1a5Upj9ahAe0hft.e uijSG8N0URwqW X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Mar 2022 19:46:37 +0000 Received: by kubenode507.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3ae5a90ba2db0832d31271a01e8a0614; Sat, 05 Mar 2022 19:23:00 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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: Panic while making buildlernel on RPi3 From: Mark Millard In-Reply-To: <3745EBFD-D97E-4F54-99DE-2EF2198BB95E@yahoo.com> Date: Sat, 5 Mar 2022 11:22:59 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220304214836.GA21411@www.zefox.net> <29044F99-661A-4C75-9493-28857DAB963F@yahoo.com> <20220305043002.GB21411@www.zefox.net> <20220305153748.GA24413@www.zefox.net> <3745EBFD-D97E-4F54-99DE-2EF2198BB95E@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4K9wGF24sdz3s79 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lIsjGbH6; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; 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.68.83:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Mar-5, at 11:11, Mark Millard wrote: > On 2022-Mar-5, at 07:37, bob prohaska wrote: >=20 >> On Fri, Mar 04, 2022 at 10:51:00PM -0800, Mark Millard wrote: >>> On 2022-Mar-4, at 20:30, bob prohaska wrote: >>>=20 >>>> On Fri, Mar 04, 2022 at 05:36:20PM -0800, Mark Millard wrote: >>>=20 >>> Are you going to do the official-builds-on-microsd-card >>> sorts of boot and try tests that I've suggested, such as a >>> 13.1-PRERELEASE (snapshot) test? (This avoids your having >>> built anything tested and all but whatever minimal >>> configuration that you need to do to allow the test.) >>>=20 >> Yes, after stable/13 settles down a bit. This failure was on >> -current.=20 I recommended a temporary experiment on independent media. Why would settling be important? If you want 13.1 to address the issue (if it has it), the earlier the better for discovering if it has the problem in official builds with minimal local adjustments to allow the test. Side note: stable/13 now has the greatly improved OOM kill messaging and so is unlikely to be misleading in notices about such. > I had also recommended doing the same sort of thing > with a 14-CURRENT snapshot: both tests. >=20 >>> Getting a failure from such an installation of official >>> installation materials might be more likely to lead to >>> getting help isolating the issue.=20 >=20 > That also applies to 14-CURRENT. >=20 >> Understood. At this point I have two RPI3 systems which >> exhibit the same problem (faulty ping response). One has >> followed stable/13 (which had the clang errors you helped >> with), the other has tracked -current. =20 >>=20 >>> [Back to the Subject line's issue . . .] >>>=20 >>>> I've been using -DWITH_META_MODE as a default setting for = buildworld and=20 >>>> buildkernel. Might this be part of my problems with the Pi3's ?=20 >>>=20 >>> NO_CLEAN is more likely to have the result messed up: it >>> does less dependency checking and can miss more that should >>> be rebuilt/relinked. >=20 > I should also have referenced WITHOUT_CLEAN these days. >=20 >>> WITH_META_MODE is likely to rebuild more than NO_CLEAN, and >>> so, less likely to include stale material. >>>=20 >>> Without special knowledge of the details of what all needs to >>> be rebuilt at the time, WITH_META_MODE is normally safer. >>=20 >> I note with interest that you say "safer", not safe. >=20 > The Makefiles themselves can still have problems. WITH_META_MODE > notes more dependencies (for next time) than the Makefile is > explicit about. But there can be other types of special handling > at transition points that Makefiles are responsible for. That > includes dealing with new dependencies that prior WITH_META_MODE > activity could not have seen yet for future use and dependencies > that existed before but that WITH_META_MODE has not yet recorded > a new lack of a dependency yet. Frequently such is handled by > extra clean-like activity that forces certain things to rebuild > based on just the older dependency information or dependencies > that Makefile* themselves would detect. >=20 > Also, files that are no longer intended to be used can hang > around and potentially be accidentally used. >=20 >> How do the >> various cleaning targets described in the build manpage compare? >> There's clean, cleandir and cleandepend, along with rm -rf /usr/obj. >> It appears cleandir run twice is equivalant to combined clean and >> rm -rf /usr/obj. I've not tried cleandepend yet, might it help? >=20 > I happen to do rm -rf explicitly. >=20 > clean and cleandepend serve different purposes. cleandir done > twice includes doing an effective clean and cleandepend at > least once. There is also cleanworld and clean universe. >=20 > QUOTE > clean Remove any files created during the build = process. >=20 > cleandepend Remove the ${.OBJDIR}/${DEPENDFILE}* files = generated by > prior =E2=80=9Cmake=E2=80=9D and =E2=80=9Cmake = depend=E2=80=9D steps. >=20 > cleandir Remove the canonical object directory if it = exists, or > perform actions equivalent to =E2=80=9Cmake clean = cleandepend=E2=80=9D > if it does not. This target will also remove an = obj > link in ${.CURDIR} if that exists. >=20 > It is advisable to run =E2=80=9Cmake cleandir=E2=80= =9D twice: the first > invocation will remove the canonical object = directory > and the second one will clean up ${.CURDIR}. > . . . > cleanworld Attempt to clean up targets built by a = preceding > buildworld, or similar step built from this = source > directory. >=20 > cleanuniverse When WITH_UNIFIED_OBJDIR is enabled, attempt = to > clean up targets built by a preceding = buildworld, > universe, or similar step, for any = architecture > built from this source directory. > END QUOTE >=20 > To my knowledge you do not build for all architectures, > just aarch64 and armv7 . So cleanuniverse should be able to > be ignored. >=20 > =46rom Makefile.inc1 : >=20 > QUOTE > # Make command line options: > # -DNO_CLEANDIR run ${MAKE} clean, instead of ${MAKE} cleandir > # -DNO_CLEAN do not clean at all > . . . > # -DNO_KERNELCLEAN do not run ${MAKE} clean in ${MAKE} = buildkernel > END QUOTE >=20 > but the actual logic is: >=20 > .if defined(NO_CLEANDIR) > CLEANDIR=3D clean cleandepend > .else > CLEANDIR=3D cleandir > .endif >=20 > so cleandepend is also used for NO_CLEANDIR . This shows the > relationship: clean cleandepend does less. >=20 > As for cleanworld ( from Makefile.inc1 ): >=20 > QUOTE > # cleanworld > # In the following, the first 'rm' in a series will usually remove all > # files and directories. If it does not, then there are probably some > # files with file flags set, so this unsets them and tries the 'rm' a > # second time. There are situations where this target will be = cleaning > # some directories via more than one method, but that duplication is > # needed to correctly handle all the possible situations. Removing = all > # files without file flags set in the first 'rm' instance saves time, > # because 'chflags' will need to operate on fewer files afterwards. > # > # It is expected that BW_CANONICALOBJDIR =3D=3D the CANONICALOBJDIR as = would be > # created by bsd.obj.mk, except that we don't want to .include that = file > # in this makefile. We don't do a cleandir walk if MK_AUTO_OBJ is yes > # since it is not possible for files to land in the wrong place. > END QUOTE >=20 > To my knowledge cleanworld is more extensive in its coverage than > any clean , cleandepend , or cleandir usage combination. >=20 > cleanworld has some fall back logic that uses cleandir once for a > particular type of context after its potenial rm -fr activities. >=20 >=20 >> It sounds like an occasional clean start buildworld/buildkernel >> would reduce uncertainty, if not problems.=20 >>=20 >=20 > It can. At times UPDATING will report needing to have cleaned > before a buildworld or buildkernel . >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com