From nobody Tue Feb 21 19:56:13 2023 X-Original-To: freebsd-stable@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 4PLqmd02Rwz3t8kf for ; Tue, 21 Feb 2023 19:56:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PLqmc47q5z44jN for ; Tue, 21 Feb 2023 19:56:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677009391; bh=b95fM1Dw4aizc13GSzUg3adxFPkgVXkkliEX1PtBBpA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=d+SJBx4HIl1WGGzhHdl0ScdiI7n+aUBI9SoCg/uM9YkBDZ/9pUUp4NarI52hHfILn2CzCfVw+Xn2nz0k48nT9rQvOKhT2djQtyyt1+CeAv0aCMPD739wUKqnqU49Ptyd9rMT/IvWGUI3+q2BwKvI3zkt63Bwun5Wql24gR3VfkdE+r/l9eNfxtehfjtWO0OOEDN6shqYfAIagMjWYvUxiEVfmEE+InKUnkhfHDJevdidtI0qn+tl4vNx0h0Tv5UKmDfOvZGOjnqgrx6b++CZx7WD8NRJ5arm2bs+9fZIOQ423gScOqkMG9HhMp2XM1FDZmvB7uB3lOSWJB6UVGTQ5A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677009391; bh=2puxN1f0U0szFZPaGafAtTPlCEd+/Jk8/RQsL+oStqy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=plLyB2zR1Ljn1vhIJtaVnoPT4Zd+oZh0Inmqg/yHH8+s75fLzs0boKoThXkiNrkC0YjMYxnj/4Hc4t2A3plwRYsLu4gEicLPYC5Ysl6bDcFwrUWve54CMkq9enXU9KA89BebXNKmPR1+tGN1CFrJfj9yfcMRu85pcG38afbUN7oKoSJoLVfltLK97WMWE1cSH7zzH1/qxsehL9tm/eWiCbPMGXTTw+PLJgpd58CdsS0rLubWBdrWYWlUjcaoxkKZjo3CfqV8Er0f9Bfr1oRY3cQJNaJLHstKzV9OQfIg+OdjuOs6SLiWnEfUppbsVjYESd5oiBKxlT00jmnzKak8Bw== X-YMail-OSG: rwtUr4cVM1mYamNUV3DdsRNyNEk.aGhTQqXJaTLVbCJbjRlqjx1sw53mbk1aza5 Q9PcJsfkP47JhtWqAWeERUkp1bXT_QSpnl45dFx4H7JuelQmskkHQXl9pqlBtoLgVwse1ES6ADQQ fQju1FxiYaNlS8HTTzBhRskTyxnfRNeLTZue0ocrfPOcc1Y6AmB6v.B6WqBBDh8Hp_7d1j6OebwZ WqAw..UuivQZz3Dx9EhL_WqWnsrRRZJTtDWHrrwPTAIO7ss.giUnLeagCLbSJp_v7aH5PoQIqBSe _sStdIiuXhZg.tlIxH7jFuc34nPjWl75GF.37t5Ug02k9E1pnVJgZcQOJMuSl88c8KdEffKFWr5y Zk6XvB4ypSwqegTN0A36OjTJFrHeCWvgBn3ZIEgLzS2NvyRT6xHSzfCezy6GICTibZVBrWhBsANq _Ci9zB2eSqkzKhgLcgUKRjLm0HJYhr5rPz4AHS4Vfbp10nNjn6DdcifIrJyKEZguEVh9s_aEv8pi ukbL0ibHxmh8GMgVbuKX4T0QD61DgeuFWXXjbvwX9y.3NlzHQC3TNdANC43LCuid8w6mk2exy5w1 QjDQGf0DzYMbx2RtZhrINUvNwsxselLVvHDTPeeE6JW62aFJM675H.E2Y9b3Lp9Nfnmy3AX7BsTV rnV4kjrNKG6yFChbTJxS.0IlZEXH8AFWVyw.xIy0Zjfc42h3cE8vgnrYTSNofn2baKu2TAD.wwHO HRVqLOQym9DUrgIgQzuGFmHa0z7Qt0V_A.Jk_MNWfA3DLtENV5iYmqowxKqfXbnXYE77ClPibJEI DHVNMgNcQrXc39c6xFW.2rEv6AMwAHBQE5x_a4mqSCXEO99dr9pXsJHLFhpWj4Pm69E4gCbmn825 4g2PVb1m4t35ZOFlkbSUKi4.WoVq3e.2RYGyv7pG.RGtQvOz2VCd4ewswavOZWp.Sda0906EfePg RbF_kNL5LeV8.P2iAZ4jxkKA7pqh49Tr_fVreRd.45Ydz1LPVP5aQXhCaBImn5KBHSL09iFDsIkT FkcFSvlRH1dn4WjXIFoUIUrneLunsux0TNFnmBTNbaeE..yosg07OK6Ug87W.S9Ek4Lzv5s2pYkw jJ9DDpO7UHw_qKOtEi9RuJQmJBD_HfSLZ.YHpxAAltULa1KjmHFldSpepDPbk7j7jnjmtOAxdcHK zD7oanxhoStJfxpjZqFEdQrFoQ261x5FTAM.Nx4uOa3a0N1_mbfYr0loVrY8SuxBeIadqXjbKuQ2 rFvFwUrtwySyShdERhGYNKq7H2Wy4PH2apR_MIlWn7nNaACnRFrJRlbMqwoKqJrXEigvYWtjMyCE SDOfqg91nItRMlNcUIS9Z0jDirTGvJ1Njujr88MxSai1Md2YjYcG1zJdv4QzW7LXcp5gIGTv6IqP sI0yn5_VBEU8tor8XVbi2.ImB1w5VsOxhYJYaoccrL4pBnw4airw4a4Hc6gTin7_yuiCK8WnI_8S 2hkeWGp4Wu122.4DrSEIvZu18RJT32SXVmdUQ4vr0Ujbg4nVXSCunM4yBUFKHkqWWhd7xE0tdSuN AM9X4PzpMulgHRRWKamYEeXZr.2AH5wKcO2XaMmtUACnzyEA0UaMhk_Q3LbCf6oRBdK6uIiW4cEm U6scWAX9l..EHJXWtpcm6WF7RLVYyFiyzkhKTuqHhvguaJkwEKjkmpUplpcwIWJHwZPSr_s56It. jkbbnpensJnaPhn8UdQDlIXESu2gYIPBsrKXrM_86rXIjNDCOb7uEt_tNlxnwKmmNq9B1ThX0heK SJZtByppADPkypPDZnnAcp6gGbVIB2Ki8HHSVe0s_WEXnAiRW7T6ylOB9DXnnooijwm.jfoWTuBl iDgmhAgj3r5AUVhjA7i0o9TghJyXG7rmOCyaMUJv9FZ4z5G2Uo9N_mkO18um7XZCrCH7jTbrIqG0 ._s1ZJTp.p8kCEaLz4Kdkm0pZqpKimkUZ6.iBYPEZ9bVM3ySVYAkqlJin4oFIPiVzBqLSURykOPj 58Z7Q_Z35U.p1zPWBXkwII6xvCvAuDz8cyoJEIMRoN_mwPbnPlWNXUVrENpXP3RyWjRPPu2VMhoo okqmYbKN5B.fIolzwsl.Ot8LoP2uGIh7mWg5rTnUbP7GdGACr07uo7Kp6vpZtG5AqcOKOi.YGJDD W9bHJvt3DrnZGPz8XDUUmnV1xI63RWXj2.PcPsKy9D5OZg8LWqormYyW2Zk1Cb0e.vxVtpp.9jxs WN2rKPzmGSwhRD_9z2_tkL94lP47zsuQwZZhJV1j8S6fNCWR07SFhy4AyHsuniqjmR7_G7OIgQb. f.g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Feb 2023 19:56:31 +0000 Received: by hermes--production-bf1-57c96c66f6-7qgxj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7bff3363b8848853dc6b50f342316650; Tue, 21 Feb 2023 19:56:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: 13.2 BETA2: how do debug META_MODE? From: Mark Millard In-Reply-To: Date: Tue, 21 Feb 2023 11:56:13 -0800 Cc: FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <41B536B0-DA66-449E-96BB-E11A8750471A.ref@yahoo.com> <41B536B0-DA66-449E-96BB-E11A8750471A@yahoo.com> To: Peter X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PLqmc47q5z44jN X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 21, 2023, at 04:55, Peter wrote: > On Mon, Feb 20, 2023 at 08:44:59PM -0800, Mark Millard wrote: > ! Peter wrote on > ! Date: Tue, 21 Feb 2023 03:45:12 UTC : > !=20 > ! > on /some/ of my nodes, META_MODE seems not being honored anymore: > ! > I had to build them another time, and the lengthy lib/clang gets > ! > built all over again (tried two times). > ! > This is so since 13.2 (BETA2). It did work in 13.1 (RELENG), at = least > ! > according to the timing from the logfiles.=20 > ! >=20 > ! > Now I'm trying to figure out the difference, because I have some > ! > nodes where it appears to more-or-less work (have seen buildworld > ! > take 5 minutes), and others where it doesn't (take an hour to = build). > ! > The thing is scripted, so it is not so very likely an operator = error > ! > (while not impossible either). > ! >=20 > ! > But it seems difficult to figure out details: "make -n" seems to = not > ! > care about META_MODE, while META_MODE suppresses all useful output = from > ! > make. And the docs say there are *.meta files (yes there are), but = no > ! > info about how to verify their content, or how to get make tell = what > ! > it is going to do and why (and the buildworld is not the most easy > ! > to understand target)... > ! >=20 > ! > So, some inspiration would be welcome... > !=20 > ! On thing to check on is if filemon.ko is loaded and operational. > ! META_MODE greatly depends on it. >=20 > That should be the case - 'kldstat' shows it (and I've seen warnings > where it didn't). >=20 > ! Another thing to know is that the following are very different > ! for what all is built for the "(again #0)" line vs. the other > ! two "again" lines, using buildworld as an example context. > ! Imagine here the the first buildworld rebuilds llvm/clang > ! materials. > !=20 > ! # cd /usr/src/ > ! # env WITH_META_MODE=3Dyes make buildworld > ! # env WITH_META_MODE=3Dyes make installworld > ! # env WITH_META_MODE=3Dyes make buildworld (again #0) > ! ## no more rebuilds below? > ! # env WITH_META_MODE=3Dyes make buildworld (again #1) > ! # env WITH_META_MODE=3Dyes make buildworld (again #2) >=20 > But what is the difference between #0 and #1? awk, cp, ln, rm, sed, and many more from . . ./tmp/legacy/usr/sbin/have new dates for rebuilds after installworld (that targets the running system). Not true for #1 and #2. The dates on these tools being more recent than the files that they were involved in producing leads to rebuilding those files. That in turn leads to other files being rebuilt. make with -dM reports the likes of: file '. . ./tmp/legacy/usr/sbin/awk' is newer than the target... explicitly as it goes. As I remember tmp/legacy/usr/sbin/ was always part of the path for what I found. One still has to trace back to were rebuild a rebuild is not due to something rebuilt in earlier in the same build. Noting that tmp/legacy/usr/sbin/awk is reported as newer than its target, leaves the question of how it ended up being newer: earlier in same build vs. before build activity? It too must be traced back to something based on just material from prior to the build in question. Note that the above make sequence was only intended for showing the dependency, not as instructions for a normal update sequence. > . . . >=20 > ! See: > !=20 > ! = https://lists.freebsd.org/pipermail/freebsd-current/2021-January/078488.ht= ml This (and later messages in the thread) are about the "awk, cp, ln, rm, sed, and many more" that make with -dM explicitly reports (likely from tmp/legacy/usr/sbin/ ). If you trust the make date comparisons, it is the easiest way to find out what has "is newer than the target" status that leads to starting a rebuild sequence. (Other dependent things then rebuild based on this rebuild. One still has to trace back to where things start.) I did not do the analysis of how (e.g.) tmp/legacy/usr/sbin/awk ended up being newer than such a target and, so, causing a rebuild of that target. I was going the direction: that it is newer really is unlikely to justify the rebuild for the target(s) in question. The other direction about how it got to be newer is also relevant. > !=20 > ! and: > !=20 > ! https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257616 . >=20 > Thank You, that's exactly the inspiration I was looking for! > Diving back in... =3D=3D=3D Mark Millard marklmi at yahoo.com