From nobody Sat Mar 5 19:11:16 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 350EE19F6B26 for ; Sat, 5 Mar 2022 19:11:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4K9vTY6BL0z3mdX for ; Sat, 5 Mar 2022 19:11:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646507482; bh=YvpnTmXWlcxyyxJgFj0teQeXqqmfmflZr9M8cm0E+tQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=MupAsqCOgfb+piqKoUeBaZ43OzABhdQNZduJV8JLOt62r3DxlgBb9ERTTnzmVsK5NQ3gHVCWg9zA3Ni2D5QmL9J+d0pKUPXnsgH2+ra8pstVevNeNRJzLuAUPuzqLtHCtN7VNsSSp0A9BdJFtjy+kXnGd6Zvuc3CZgkw8cEU6x9SESGEVqjPXDimkBFm+Ud53rNHoeGetkiCr0TVsQaMmnpXi9lspF5YW6xnGzXZp0ZuNtZAgMzd8zuC5bdbqjMixSuhVOqtztJ2+eeXvEdOV4dUaVYq5L5n0yZzUPmMDf5RKgH5tyqFTyWd0MmaWTIa20xP/rkjlPrnLymYPoV5gQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1646507482; bh=AxIXqBcwH9w/l8gq93VcatCGOYeW3F0hg9u+dRl3Xsa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=j1GYNGuYZYvo3Gd/NxzxyAc8xo9sfE/+3gWea+//WeJ8NqVEio08gvT8CcNOV3SI8W6xQRJ2fizTEUDjP7p3DKFX0DCZ1/ifO8LY6fJFtzjB2xWsY+h02nHAakn7FFmo+MAGws0Bs3pwrKDmgah3lrN27C8LQ9KT9m8olursFIRWGCfI3sAyA3Pn3AhfpgyrLqilBEhSvAHEjZXCwTP9OKQpfFSK1tMF6Cnzrd4h1DFGcd3Q88C+k8TNhxKyszbgZai+7cKFTAS6R6p4GHld0LRAOxLuBnsagfjXDPAQemFOwJIgaHRaKbk+1Y5Ux9xXYY77+Avz4auxkDJa9wCewQ== X-YMail-OSG: Cv.mfTgVM1ljntC40NpXOKIcE6YCxT24p8bgaj_BOiJWDzglaxZ1WS67DXcGQWG EA20DzJ4TYsXUaEF0pgqDNQPBj4dxrB1Cb4Tw6G0Oh7515lpk8dQD7hjyVK_6j2HWZHOepGFDR_r R9yei1Kvb4I.21wq3qDCpIdTDTvnIenXObJAW5tBoBoH_OzcH0utLYZSvgjHV6PZDe9e99MXSkOk xINaYRbKj4CPn2Bemcm1zA9vfnjqdFeZOxib6LamQ5yEZ9DequzsljZEcJ6o2qGC0jQ6WK0eTAzP JZ1GxZcdaysczRcme7a2YNlrFFzNr5NKHCyoZK66AzNnOvanuUmDTGsrWqWtjBDy2aZ.hFLRiAjP Cg1IfY1eDfdPd0on_iFnUdnQgxSbx3MugHCHxljCNR2SP8TF5lCxuiy0gzJN3TFLu4R9xR1lBCNr gA9n9GOvaDPXSdrgE06P5OCWjEnqjSg1AmncBj1PLyXw0i.6Rcy3d4Xqnhe9ozyWgKbB1YduLBo5 6ATbthQGCKLpNP7VU84fkjom13f3QJOX9n6XqiBNN3LFFBwUv1EbkzKYMiDhJxwbA0MyNExE6kPs XN0lVsbHXdCxQAgZF1PfwSZGBCYjlyoqJ0Y2gJY75aviC.xlVcGjaGPeFHABmdV65sxQvMXtAjX9 a6iK8u3fPjRHe5ETdYr1FBus48.ueTxlJUJfwWqmBZbbo1QdghRcSPvvArXA4ErHI61._C9dK4Ou JzK9g6YXRLSJ6v3C3TKU83AxqYGNO1I3lsnaLN5qc9RO1.KvnPu_QEN80eAw3jYpDE1Qmzv1iMBG f7laCQfb2bFtrZFZ9S51j_YnzgcnmIqPE1YH2fJGnvNWxCIm3MLN6BRprGzNYaRqs_gfJcXVuLZY GeY1T0pS1CuPjoMWZMli9pCvBh0.5XqO3sygM.0FPR3F_AZ071tBZHBHNsi9GJsicFC56N7sGFVw sJUyuqp4iwSaQ6sTfcAmeTXjy53mvdGJpMkCaI5ey95oso2wy1KlmbGrsH3p7ukypGN9d_Nj.Z0b YNClvw5DJgXKxEvNvDa3UrJ_PXz2tdgRlx2GpJ9OZVIKStZXDHVo1LKMlGGgFJK2O4S6KA04i_iC lxt0aqwxtoq4H_AJVvTTGaw3LLsq3wAhstLQItm71MFlTUC.QmvsJYk47P.HtTDCEs6iyobJQx_. P_FoFroR1zuyl4JIzLXiCkD1vWrX.KM3Tm9cvCwbS6HdyEQaH3JlK7Cu9sOF_KTZYDzGHUzOadli rxekJY4X1q9tT2J1XRf4FTCkf63xT1Cs2LcHZomkAb4TtyoP12sAGJZzOBIXtxEgiysCxHYFTAbH LfVCWDeEUjzIQ_d0AmHa.PCt.aSGd7Al6WTseGG.0YRBKizrP0wGEI03WgUH23I0Rf9mrLI6hsLO IGEoZhkgO6dxFgjWSr.tThlPrgdbFzIJS_jGVSqGF8HwdaCYT9dz0c7_FbotEg.yf5MlxpP2KMiU K_1N6FxwdrnXklkTmkcC6fyHA88NL0wR.P8YOsn.Enisc._HsjJXdCbyKHCkZkqAajfHWXtYDqX5 Y9CdTRoLhe63lRNjitORR6XhX7dF4Lt0ZduBznVIq9GHqxVo7fYViDm.DgQYruJkoj2XbLr9kT_e 8SwHwOYa5aYxkvym1k8IgXgOnllAS845VRY_LnBgRloUgdrx6QHJByar1PiMfAqmpNNQCcG41xsG Wq7nK9mlZXJrRGgAfERgcQdy9WtY.RZo7Cav1UOgd0t8_8ofnWQrpD9SULwvK5XMpl.oQ5G2B94. PU6PUlANgeAGTQLGRYiH4UK3uuQl2r5ogyGQhiUUIzw_uBAZ6mxRjvzL2gx89MeYkjlQi7uK0dNA WfkiVGFa0TblQPU_2q4II4vgVQsXE6yq6kwROLUG7WTfMXwrSm3BOIb2HpZ_rXZIiLdC7oLa6d_r x2TkspYHrCtBrNmcWdMYA7g99nlpUbp7moBjotdgf2RNwr_fAM1MljtYejA1KKh9obTxGcdClkgH 5EWVC5peq1u.AiDRf1ZoxG4HjEZuIERsiRXhnm6FrHwVBk1BGiURWRaUDOr2HrGp4mLrbmCx9EEx ukQAcVvP7N67yPOR532N_eYudkGH3QuHWVnnaCaKyfpRLKOHGj1siHNjkqOjshDAB0s03.E.m70S .NzsGevyU.eHAybX3C_UzAeGocvlEZQd61ROCvrFNCQOvD7INLUdS0Ed.FiRhjGBXRzrq0SlM7Op lO2Z0Rvi6B7kfBzix0eDNoFDdj3UvnGrCE7qUNWu4jLpROdWcDyfszgMsI2QLmM.DE0oOn.FpF3G oFYSEFHTHCgk- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 5 Mar 2022 19:11:22 +0000 Received: by kubenode523.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d589183c3f39e772b79c0bd3c5d00da3; Sat, 05 Mar 2022 19:11:17 +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: <20220305153748.GA24413@www.zefox.net> Date: Sat, 5 Mar 2022 11:11:16 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3745EBFD-D97E-4F54-99DE-2EF2198BB95E@yahoo.com> References: <20220304214836.GA21411@www.zefox.net> <29044F99-661A-4C75-9493-28857DAB963F@yahoo.com> <20220305043002.GB21411@www.zefox.net> <20220305153748.GA24413@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4K9vTY6BL0z3mdX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=MupAsqCO; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.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.64.83:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6547 Lines: 179 On 2022-Mar-5, at 07:37, bob prohaska wrote: > 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 had also recommended doing the same sort of thing with a 14-CURRENT snapshot: both tests. >> Getting a failure from such an installation of official >> installation materials might be more likely to lead to >> getting help isolating the issue.=20 That also applies to 14-CURRENT. > 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. I should also have referenced WITHOUT_CLEAN these days. >> 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. 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. Also, files that are no longer intended to be used can hang around and potentially be accidentally used. > 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? I happen to do rm -rf explicitly. 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. QUOTE clean Remove any files created during the build process. cleandepend Remove the ${.OBJDIR}/${DEPENDFILE}* files = generated by prior =E2=80=9Cmake=E2=80=9D and =E2=80=9Cmake = depend=E2=80=9D steps. 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. 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. 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 To my knowledge you do not build for all architectures, just aarch64 and armv7 . So cleanuniverse should be able to be ignored. =46rom Makefile.inc1 : 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 but the actual logic is: .if defined(NO_CLEANDIR) CLEANDIR=3D clean cleandepend .else CLEANDIR=3D cleandir .endif so cleandepend is also used for NO_CLEANDIR . This shows the relationship: clean cleandepend does less. As for cleanworld ( from Makefile.inc1 ): 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 To my knowledge cleanworld is more extensive in its coverage than any clean , cleandepend , or cleandir usage combination. cleanworld has some fall back logic that uses cleandir once for a particular type of context after its potenial rm -fr activities. > It sounds like an occasional clean start buildworld/buildkernel > would reduce uncertainty, if not problems.=20 >=20 It can. At times UPDATING will report needing to have cleaned before a buildworld or buildkernel . =3D=3D=3D Mark Millard marklmi at yahoo.com