Date: Sat, 5 Mar 2022 11:11:16 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Panic while making buildlernel on RPi3 Message-ID: <3745EBFD-D97E-4F54-99DE-2EF2198BB95E@yahoo.com> In-Reply-To: <20220305153748.GA24413@www.zefox.net> References: <20220304214836.GA21411@www.zefox.net> <E30ECA49-14A0-49A1-9B36-BE25FD646CBF@yahoo.com> <29044F99-661A-4C75-9493-28857DAB963F@yahoo.com> <20220305043002.GB21411@www.zefox.net> <F1499C1E-4959-434A-A114-4B0496C2429A@yahoo.com> <20220305153748.GA24413@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Mar-5, at 07:37, bob prohaska <fbsd@www.zefox.net> wrote:
> On Fri, Mar 04, 2022 at 10:51:00PM -0800, Mark Millard wrote:
>> On 2022-Mar-4, at 20:30, bob prohaska <fbsd@www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3745EBFD-D97E-4F54-99DE-2EF2198BB95E>