From nobody Mon Apr 14 13:14:39 2025 X-Original-To: current@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 4Zbnnf6nBVz5sp7T for ; Mon, 14 Apr 2025 13:14:46 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4Zbnnb5gxFz40fp; Mon, 14 Apr 2025 13:14:43 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dec.sakura.ne.jp header.s=s2405 header.b=Zp+UCthE; dmarc=pass (policy=none) header.from=dec.sakura.ne.jp; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp Received: from kalamity.joker.local (124-18-43-114.area1c.commufa.jp [124.18.43.114]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 53EDEdaB027603; Mon, 14 Apr 2025 22:14:40 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1744636481; bh=PA7gwGWnQ8Ylee0X4sEaSs3zYCozXuK8Z+BqmAQ747A=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Zp+UCthEjcJa4J1ktnVdbzONBJZK3gosvfX7v8bXzm0XtW4ov2Vdy2LUwGGq4onRP Xz2MLvzFt2BvZQBkMBOsr1bhxwB1+F1BfnQZBuoOuQZbv51wrNv+zgrRVQooFGxQwD Im6KdhWbjmgvFs+LFvqfUQYirxI62CE8kRuqfL3w= Date: Mon, 14 Apr 2025 22:14:39 +0900 From: Tomoaki AOKI To: "Alexander Ziaee" Cc: "current" Subject: Re: Enabling Spleen 64 from boot Message-Id: <20250414221439.b472a37ebdc6751a0b164853@dec.sakura.ne.jp> In-Reply-To: References: <20250413102213.c592a25e8390bdc9aa54cd30@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.2) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [2.44 / 15.00]; RBL_SENDERSCORE_REPUT_5(1.50)[153.125.133.21:from]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.944]; NEURAL_SPAM_MEDIUM(0.58)[0.579]; MV_CASE(0.50)[]; URIBL_RED(0.50)[dec.sakura.ne.jp:dkim,dec.sakura.ne.jp:mid,dec.sakura.ne.jp:email]; ONCE_RECEIVED(0.20)[]; BAD_REP_POLICIES(0.10)[]; HAS_ANON_DOMAIN(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_DKIM_ALLOW(0.00)[dec.sakura.ne.jp:s=s2405]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; HAS_ORG_HEADER(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[dec.sakura.ne.jp:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; DMARC_POLICY_ALLOW(0.00)[dec.sakura.ne.jp,none]; R_SPF_ALLOW(0.00)[+ip4:153.125.133.16/28]; MLMMJ_DEST(0.00)[current@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4Zbnnb5gxFz40fp X-Spamd-Bar: ++ On Sun, 13 Apr 2025 02:02:28 +0000 (UTC) "Alexander Ziaee" wrote: > On 2025-04-12 21:22 -04:00 EDT, "Tomoaki AOKI" wrote: > > On Sat, 12 Apr 2025 23:35:02 +0000 (UTC) > > "Alexander Ziaee" wrote: > > > >> Hello, > >> > >> I'd like to enable spleen 64 in the build. It provides 80x25 character console on my 14" 2560x1600 display. I don't understand Makefile very well, but it is working on my machine. Attached is the review. > >> > >> [0]: https://reviews.freebsd.org/D49768 > >> > >> Best, > >> Alex > > > > If the problem is NOT in building the font itself, commenting on > > the review would be pointles, so commenting here. > > Is the font itself built fine reproducibly? > > For now, assuming it's OK here. > > And also assuming the problem is in console (vty) after loader > > invoked kernel. > > This is a good catch. I edited the commit message to attempt to make it more clear, did that help? > > Thanks, > Alex Looks clearer than initial version to me. Hope any of the reviewers confirm and handle it if they think it fine. -- Tomoaki AOKI From nobody Mon Apr 14 23:43:57 2025 X-Original-To: freebsd-current@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 4Zc3m05JqPz5sVBC for ; Mon, 14 Apr 2025 23:44:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4Zc3m00t6Pz3F4l for ; Mon, 14 Apr 2025 23:44:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=QgYsK0bR; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744674250; bh=7mDQxwoAEi90LNsR5iuzQy/cIjqo5n6GgbT2QTIPNBE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QgYsK0bRaymtKeIo9V+E5pe9rvXC2oR7dQ9ogVY5bmsWsQ5DhZvL2Rs+NPeRaBmsCH6ccbPy+8jNYx3hh8NAPaRzjUTkgr28z4buisL7mpHApdMAM8i6+cSXW2MKzvj7Wy9o3mmGhk21FtDtnjohNLHH5lqGDRA7NdoCUtljSK/xNO8UBKuzcR8kqUabxS4dDKJxeXa/Si5FxNOGz2fZw53XQThVBTphXro44iIczOJm93tzeXcTi338HiXbQW2HR+vELPFigfoY+s+3LtwQ7lUogURBlSlaH0j/2Fq/r6cGYa7Ur+QH/6WpEjCDPh3wqMYMmJw+o2H9hdDwMJvYrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744674250; bh=e1ckDVOayS6HYXgGDruQn8/1P3QgZRucItavwgR6BM5=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OE0PWgEKReQsjiWE4237uB2srh8X+BUrVqn285gE3lGOa14vcp5OrJlX+LLuul9LDIbC4dwEfG13XvlrQD+d9Ds2JbTlDcnfyfk+mrWCYMDdC5PE7wUwbIiOAjgu6DNNx77frMpBG/fhxgW0nRx1HWccagna4aYCZ7FoIuGOtUiNfFVPRQ+DgWg3qPfi69sVwqqM69KyXUrrgvLoxLL4hjiKEN8pGHQmKYBYjuIkSH07AbgyU4wwA3OC5+sRm6mmSuBYwIFDncG1K+Je2NcByUbAqFI2SuCHoYrf9zmc7N+FYEKQPyxHYzx2P07DBFwiD7StRIRUYTOiCqgRvWm9Bw== X-YMail-OSG: xY0jMogVM1nzyQGQV8S0gdxHK8jogRMoWi4Zaakt1NPbmDi3pZ70fRilbLcPg.G tRl0tqiLudSht8HntZ5N.wV4G2hqfDXH1sbfmo91GCIECXV_16JvGpddwdhrxY70aDqid8JztHuu azvDEJ2Tt.GTg3ZirNVYC7UB.RH8gZdTxwMT3LuM_EbMPIyykP402pbSY7KZG7qYhoaxrbbTklvr z51LLmsG746xFms4.SK7NRbXWMoXjP5d7z7dyUXQXxdf1W48bVOZiIDIohqB1zZmKz0A4kM6pHM7 yF7c86syjMWafXEcFX2i4IK0IY4lIxnPrPiuxaQnkqS7vhBpmpTzggzynUQMFZR7KbGxShE7Mf5n jhQPBWL_xFJirWIJY5aYOl_hOJBcM_Ti2ZSn_9.O8wxL_b6LCXzS.ECnuUBQAf92Nro2oFWxmyQb uwF_MkYAGrygb2akvUrqzH0RHN1.ba3t0wKEChl34BWK2nwpwI8_iuWgzuKh2R2SQR1HLaeQPD_q lqkoIEijCZczhANR11BOLi8Lkelf3PqpD01OHbV0aPxBo.kiHWT9kYo7oYvVFc6fEu3U01Bt7ZI1 p4CsVKRabnquf.PvGspjueUfaPjbAdgQ4cDwOMVDZpkx.X8fDVUEDRs9n_E.5qJ2..Lfrjn0idPD jmpZwlfsiRQpqJ7WuDrVW_QK695U9Udf.zA2uKw1A93t65ovbzBJ5VFli8Fif_f6.FzKKeq.Kbk1 _SNByBVxShH8rw9DwQQeEyTsyEUfTO1gJ6YSfB5X9j_T00zo0hPb7huDmb.vZCv1.qb.AXvKKSpH c1ddyQXIaya3RvHRn32cz1hLdLum8nmbhMGMqo6YM.g9ywJG1P.rbfnGqcH636k7_DaDcGp4wVjp uu5eL4XichjJmyTKIAfBWyuUwkCNnDM6ZrqghLM9B4a4XCa36PYDuPu_vprUvPtmDYY_6ROAXXus lfXPQtEycs2kz0m47naSg9MAIfbtjkLiMuHS4sQTeE0wIRMSuQF.0Jo4WV_gDU2PEHXS_TtIWt7a kOuAtDiCqlUOak_e_aaeDe0pvUnoD2A3cc4y7a26f7HJoeA8Kp5dtU5z9ZCsLvZ2W9enbOho4Rvg w3M87SzWXqvVqiUdrHtLQf4elL_z.kp1W_nOMpk92Q81S2.qvhHM_Lj7RdRgYrLFF69oUSZ8wUZG 3021ntbu54i5bkXhkpbRroa9bcFPMjBaWw6YzUQQku3vW249ZJlzUoJxVoIGaDXdCD7DTF4iU04P 0RhrxjleXsiNkyOsZ9OwRD6gp6Mr1I_SsMI9yFsYwGZdD9dRIsnCaz0PUD4rbIeces_SO_pCMgia An4X0UMEhuMH_4Nj67RwMa1Df0prBsh2N21tXkAQTdNRB4wHiWYOE_ehTc14smneIttvIhy8ud7C E2Tuazl_TcBMFQfpCnf8HTelbsqRPvsGkS2ZVyRoM40mFj.YlPkNblLrb_tmYJ__6UeJzBVawje9 Eo8X48z0_lab4h3bEAS0Om2LMaPnjHvQiZphTM9b2ym9ZCtaftNfbJvoZMw7sevP9RJY8V4.qsXb Edwdj5m.YxMYYlHESFfgih5oPsPC4YPFiF7CCf8wtatAa.MImTnQKbGGhsk6srOvgnuB1bTX0_dn jOGZW0PF5iPM09J8PkKGL8ZqqmHBSRSy5OHlcjp7TOIqDAbLO3RdMUyG9Hl0CAWIaTGwx422rgki e4GHaPkMA_uVTCWRmUzQpqldc.YMLaL.MsSUFiS6w6r.iLOP5RD7N.3DVTH_DBrajryAjmX8HmsZ 4X6qBLMVsBY3Hq2tCem865u6.qRNLLO5l0SlyZ6VVUrqHTuZH9wnrkIGXeW_cSFNGU_wXqZ2SIMa JwdO2jrzVmfcW_gr1S0kAhVkwPBCG8cpVq_4._sT7JKhNKC_7.klzid9pAQIlLgeYpa0C5UkF2JB c8.qKdLH7hrlBseYMW.3GGYnXvYy2eAes9k5ia3UdOTHs8I3FK4z3Kz8sVjNl.yUDs.zvB_mVmuT uzp0oQgkJtvMl_MHVYFr44ZjpUfsTljZs2OR4EnAwubD3R77RwH6HczzWSt5qbOxB.wrcauXEioo 1SSWG.NGkYK.8WxJLEiT7FNaCWVcav3Lg6mESW1UVt9e3ohnUCofhUyUSUX4c5GwOLf3iYElF7Om JoUcts0DTfuVeA3bcrk3_sFQgNTvcxunJrRZjDvdRlPNmWsNK1kH6XbiU8cs6EIuQu1UIgYRVqcR QCJeeLUUqWxBv.vYXuA35B9DDHzrJXEgDcp6Rkgb7HzJa2xmZcOeVCFjeFNceiUTroE0wgQhTID_ vqOw- X-Sonic-MF: X-Sonic-ID: 02f733f9-498d-43fc-b8f9-4e9d20a00ced Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 14 Apr 2025 23:44:10 +0000 Received: by hermes--production-gq1-74d64bb7d7-dp9cd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ad230736f6e251cf689cf2f3679cb732; Mon, 14 Apr 2025 23:44:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes] From: Mark Millard In-Reply-To: <6C67E39F-3634-4AF6-95EC-46159E7391E5@yahoo.com> Date: Mon, 14 Apr 2025 16:43:57 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <8308705D-5155-48B2-ADFC-2BCF32F7D55C@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <8B070D1D-0524-4DA4-A5C2-EF2CF98C5E15@yahoo.com> <7A1322FA-A118-4F87-9D96-DE8B05E09424@yahoo.com> <6C67E39F-3634-4AF6-95EC-46159E7391E5@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-0.84 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.64.206:from]; NEURAL_SPAM_LONG(0.99)[0.994]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-0.42)[-0.421]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.09)[0.086]; FREEMAIL_FROM(0.00)[yahoo.com]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4Zc3m00t6Pz3F4l X-Spamd-Bar: / On Apr 11, 2025, at 23:55, Mark Millard wrote: > On Apr 11, 2025, at 19:28, Mark Millard wrote: >>=20 >>> . . . >>>=20 >> . . . >>=20 >=20 > . . . >=20 >>=20 >>=20 >> Back to the originally intended content . . . >>=20 >>=20 >> On Apr 11, 2025, at 14:04, Mark Millard wrote: >>>=20 >>> On Apr 11, 2025, at 11:39, Mark Millard wrote: >>>=20 >>>> On Apr 7, 2025, at 08:14, Baptiste Daroussin = wrote: >>>>=20 >>>>> . . . >>>>> the problem we have is the >>>>> performance changes depending on what is happening in parallel on = the machines. >>>>=20 >>>> In separate list messages I've provided multiple examples >>>> of the time-taking issue that do not depend on what is >>>> running in parallel on the machines, no parallel builds >>>> involved. >>>>=20 >>>> Part of the issue is that there are thousands of examples of >>>> "small build-step time" packages for which the build-depends, >>>> lib-depends, run-depends combination, takes notable time, >>>> given that the total time contribution across those thousands >>>> of package builds is notable overall. >>>>=20 >>>> As stands, mostly it is the early part of "bulk -c -a" avoids >>>> the issue via building packages that have no or few >>>> dependencies. Later "small build-step time" packages tend to >>>> have various dependencies, greatly changing the time scale >>>> for their builds. Few builds are of "large build-step >>>> time" packages (relative to there being 30000+ packages). That=20 >>>> has implications for there being 30000+ packages to build for >>>> "bulk -c -a" or other builds with large numbers of packages >>>> to try to build. >>>>=20 >>>>> which makes the performance issues invisible on local poudriere if = you want to >>>>> test it on port A or port B, >>>>=20 >>>> I've provided counter examples to that that only involve the >>>> one builder, after the prerequisites have already been built >>>> (same or prior bulk run). >>>>=20 >>>>> if we want to reduce the performance penalty we >>>>> need to be able to make a reproducible case which can then be = profiled, to know >>>>> where to optimize if needed. >>>>=20 >>>> I've provided examples of such . . . >>>> (time intervals shown are from the aarch64 >>>> Windows Dev Kit 2023 with just the one >>>> builder active) >>>>=20 >>>> www/rt50 >>>> build-depends: 00:00:27->00:08:46 >>=20 >> More detailed comparison/contrast of non-parallel builds: >>=20 >> A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >>=20 >> [00:01:11] [01] [00:00:00] Building www/rt50 | rt50-5.0.7 >> [00:01:14] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = check-sanity >> [00:01:14] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = pkg-depends >> [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = fetch-depends >> [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: fetch >> [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: checksum >> [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = extract-depends >> [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: extract >> [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: = patch-depends >> [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: patch >> [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: = build-depends >> [00:01:24] [01] [00:00:13] Status www/rt50 | rt50-5.0.7: = lib-depends >> [00:01:24] [01] [00:00:13] Status www/rt50 | rt50-5.0.7: = configure >> [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: build >> [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: = run-depends >> [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: stage >> [00:01:29] [01] [00:00:18] Status www/rt50 | rt50-5.0.7: package >> [00:01:50] [01] [00:00:39] Finished www/rt50 | rt50-5.0.7: Success >>=20 >> A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >>=20 >> [00:03:04] [06] [00:00:00] Building www/rt50 | rt50-5.0.7 >> [00:03:06] [06] [00:00:02] Status www/rt50 | rt50-5.0.7: = check-sanity >> [00:03:06] [06] [00:00:02] Status www/rt50 | rt50-5.0.7: = pkg-depends >> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = fetch-depends >> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: fetch >> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: checksum >> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = extract-depends >> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: extract >> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = patch-depends >> [00:03:08] [06] [00:00:04] Status www/rt50 | rt50-5.0.7: patch >> [00:03:08] [06] [00:00:04] Status www/rt50 | rt50-5.0.7: = build-depends >> [00:16:26] [06] [00:13:22] Status www/rt50 | rt50-5.0.7: = lib-depends >> [00:16:26] [06] [00:13:22] Status www/rt50 | rt50-5.0.7: = configure >> [00:16:27] [06] [00:13:23] Status www/rt50 | rt50-5.0.7: build >> [00:16:27] [06] [00:13:23] Status www/rt50 | rt50-5.0.7: = run-depends >> [00:16:28] [06] [00:13:24] Status www/rt50 | rt50-5.0.7: stage >> [00:16:30] [06] [00:13:26] Status www/rt50 | rt50-5.0.7: package >> [00:17:03] [06] [00:13:59] Finished www/rt50 | rt50-5.0.7: Success >>=20 >> (That I got the 00:13:22 is interesting, given the prior >> 00:08:46. May be the A78C cores were used instead of the >> X1C cores? May be that there were no builds, just Inspecting >> activity for the prerequisites. Did I not match the USE_TMPFS >> settings? I expect that the general structural conclusions >> are not invalidated.) >>=20 >>>> devel/py-inline-snapshot@py311 >>>> build-depends: 00:00:01->00:00:55 >>>> run-depends: 00:00:56->00:01:47 >>=20 >> A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >>=20 >> [00:00:54] [04] [00:00:00] Building devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1 >> [00:00:54] [04] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.18.1 >> [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: check-sanity >> [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: pkg-depends >> [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: fetch-depends >> [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: fetch >> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: checksum >> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: extract-depends >> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: extract >> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: patch-depends >> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: patch >> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: build-depends >> [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: lib-depends >> [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: configure >> [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: build >> [00:01:02] [04] [00:00:08] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: run-depends >> [00:01:03] [04] [00:00:09] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: stage >> [00:01:03] [04] [00:00:09] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: package >> [00:01:04] [04] [00:00:10] Finished devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: Success >>=20 >> A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >>=20 >> [00:02:46] [02] [00:00:00] Building devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8 >> [00:02:46] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 >> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: check-sanity >> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: pkg-depends >> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: fetch-depends >> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: fetch >> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: checksum >> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: extract-depends >> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: extract >> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch-depends >> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch >> [00:02:48] [02] [00:00:02] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build-depends >> [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: lib-depends >> [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: configure >> [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build >> [00:04:00] [02] [00:01:14] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: run-depends >> [00:05:27] [02] [00:02:41] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: stage >> [00:05:28] [02] [00:02:42] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: package >> [00:05:28] [02] [00:02:42] Finished devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: Success >>=20 >> (Again longer 2.1.0 times vs. previous 2.1.0 times.) >>=20 >>>>=20 >>>> mail/mailest@nox >>>> build-depends: 00:00:01->00:00:28 >>>> run-depends: 00:00:30->00:00:59 >>=20 >> A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >>=20 >> [00:00:58] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 >> [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity >> [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends >> [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends >> [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch >> [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum >> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends >> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract >> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends >> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch >> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends >> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends >> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure >> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build >> [00:01:03] [01] [00:00:05] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends >> [00:01:08] [01] [00:00:10] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage >> [00:01:09] [01] [00:00:11] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package >> [00:01:09] [01] [00:00:11] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >>=20 >> A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >>=20 >> [00:02:50] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 >> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity >> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends >> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends >> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch >> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum >> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends >> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract >> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends >> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch >> [00:02:52] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends >> [00:02:52] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends >> [00:03:31] [01] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure >> [00:03:31] [01] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build >> [00:03:32] [01] [00:00:42] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends >> [00:04:08] [01] [00:01:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage >> [00:04:08] [01] [00:01:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package >> [00:04:09] [01] [00:01:19] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >>=20 >> (Again longer 2.1.0 times vs. previous 2.1.0 times.) >>=20 >>>>=20 >>>> devel/dwarves >>>> build-depends: 00:00:05->00:02:23 >>>> lib-depends: 00:02:23->00:02:42 >>=20 >> A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >>=20 >> [00:00:56] [07] [00:00:00] Building devel/dwarves | dwarves-1.19_3 >> [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = check-sanity >> [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = pkg-depends >> [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch-depends >> [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch >> [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = checksum >> [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract-depends >> [00:01:01] [07] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract >> [00:01:02] [07] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = patch-depends >> [00:01:02] [07] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = patch >> [00:01:02] [07] [00:00:06] Status devel/dwarves | dwarves-1.19_3: = build-depends >> [00:01:07] [07] [00:00:11] Status devel/dwarves | dwarves-1.19_3: = lib-depends >> [00:01:08] [07] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = configure >> [00:01:08] [07] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = build >> [00:01:13] [07] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = run-depends >> [00:01:13] [07] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = stage >> [00:01:13] [07] [00:00:17] Status devel/dwarves | dwarves-1.19_3: = package >> [00:01:14] [07] [00:00:18] Finished devel/dwarves | dwarves-1.19_3: = Success >>=20 >> A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >>=20 >> [00:02:54] [05] [00:00:00] Building devel/dwarves | dwarves-1.19_3 >> [00:02:58] [05] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = check-sanity >> [00:02:58] [05] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = pkg-depends >> [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch-depends >> [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = fetch >> [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = checksum >> [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract-depends >> [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = extract >> [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = patch-depends >> [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = patch >> [00:02:59] [05] [00:00:05] Status devel/dwarves | dwarves-1.19_3: = build-depends >> [00:05:33] [05] [00:02:39] Status devel/dwarves | dwarves-1.19_3: = lib-depends >> [00:06:07] [05] [00:03:13] Status devel/dwarves | dwarves-1.19_3: = configure >> [00:06:07] [05] [00:03:13] Status devel/dwarves | dwarves-1.19_3: = build >> [00:06:12] [05] [00:03:18] Status devel/dwarves | dwarves-1.19_3: = run-depends >> [00:06:12] [05] [00:03:18] Status devel/dwarves | dwarves-1.19_3: = stage >> [00:06:12] [05] [00:03:18] Status devel/dwarves | dwarves-1.19_3: = package >> [00:06:12] [05] [00:03:18] Finished devel/dwarves | dwarves-1.19_3: = Success >>=20 >> (Again longer 2.1.0 times vs. previous 2.1.0 times.) >>=20 >>> net-mgmt/fastnetmon >>> build-depends: 00:00:03->00:00:42 >>> lib-depends: 00:00:42->00:01:29 >>=20 >> A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >>=20 >> [00:01:00] [02] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 >> [00:01:00] [02] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity >> [00:01:00] [02] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends >> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends >> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch >> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum >> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends >> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract >> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends >> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch >> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends >> [00:01:03] [02] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends >> [00:01:07] [02] [00:00:07] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure >> [00:01:10] [02] [00:00:10] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build >> [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends >> [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage >> [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package >> [00:03:18] [02] [00:02:18] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success >>=20 >> A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >>=20 >> [00:02:54] [06] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 >> [00:02:55] [06] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity >> [00:02:55] [06] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends >> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends >> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch >> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum >> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends >> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract >> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends >> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch >> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends >> [00:04:10] [06] [00:01:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends >> [00:05:41] [06] [00:02:47] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure >> [00:05:44] [06] [00:02:50] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build >> [00:07:43] [06] [00:04:49] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends >> [00:07:43] [06] [00:04:49] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage >> [00:07:44] [06] [00:04:50] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package >> [00:07:46] [06] [00:04:52] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success >>=20 >> (Again longer 2.1.0 times vs. previous 2.1.0 times.) >>=20 >>> (See later below.) >>>=20 >>>> The timings are from the column next to >>>> the Building/Status/Finished column from >>>> using bulk -v , not from the column for >>>> the overall bulk run. >>>>=20 >>>>> I have tried to reproduce each individual case which happen in the = ports tree >>>>> and I am not able to reproduce them, so impossible to know where = to look at >>>>> exactly. >>>>=20 >>>> Try some of the examples that I've provided? >>>>=20 >>>> There are more examples that I could check >>>> and report non-parallel timings on if you >>>> want. I just picked to report on only a few >>>> initially. >>>>=20 >>>> An example that you might want is my >>>> providing more examples of lib-depends >>>> with non-parallel timings. >>>=20 >>> I took a quick look and quickly ran into: >>> (aarch64 Windows Dev Kit 2023 no-parallel-builders >>> timing again, after having built the prerequisites >>> that had not previously been built) >>>=20 >>> [00:11:37] [01] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 >>> [00:11:39] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity >>> [00:11:39] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends >>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends >>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch >>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum >>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends >>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract >>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends >>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch >>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends >>> [00:12:19] [01] [00:00:42] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends >>> [00:13:06] [01] [00:01:29] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure >>> [00:13:09] [01] [00:01:32] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build >>> [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends >>> [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage >>> [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package >>> [00:14:22] [01] [00:02:45] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success >>>=20 >>> (I still have thousands of packages that have not built >>> in the bulk -v -a build activity. The M4 MAX is in use >>> for that.) >>>=20 >>>>> I know what is new and what causes the performance penalty, but = not >>>>> which part is causing the super extra penalty on the cluster. >>>>=20 >>>> Various examples reproduce the timing issues >>>> outside the cluster and without the parallel >>>> builds. These results are from the M4 MAX context for pkg 2.1.0 use. I finished a "bulk -a" sequence (without having kldloaded linux = support). So I can now do the likes of: # poudriere bulk -jrelease-aarch64 -v -p alt -C www/gitlab@ee without having to build the prerequisites. No parallel builds involved. For that specific example I'll do it once before rebooting and once after, checking on caching effects. FYI: [00:05:28] Building 285 packages using up to 12 builders (But the prerequisites just get: "Inspecting . . .: determining shlib requirements", no actual builds.) I'll not repeat that part below. I'll also note that "Creating pkg repository" after such a build seems to not be an incremental activity for the small number of packages that change (1 here): (before reboot case) [00:29:41] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [01:34:32] Committing packages to repository: = /usr/local/poudriere/data/packages/release-aarch64-alt/.real_1744660767 = via .latest symlink (after reboot case) [00:28:08] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [01:29:53] Committing packages to repository: = /usr/local/poudriere/data/packages/release-aarch64-alt/.real_1744668230 = via .latest symlink (I'm not so sure if the pkg-static threads for my context mostly end up waiting for each other, the "gstat -spod" L(q) generally showing 16..22, sometimes more. biord and getblk commonly show in top, with at most 1 CPU? showing.) The 1hr+ extra makes experimenting more time consuming. I'm glad it is the faster M4 MAX as the context. It also means that I'm unlikely to try such on the Windows Dev Kit 2023 where the time could be much longer. Before reboot (but after bulk -a): [00:05:44] [01] [00:00:00] Building www/gitlab@ee | gitlab-ee-17.10.3 [00:05:46] [01] [00:00:02] Status www/gitlab@ee | gitlab-ee-17.10.3: = check-sanity [00:05:46] [01] [00:00:02] Status www/gitlab@ee | gitlab-ee-17.10.3: = pkg-depends [00:05:46] [01] [00:00:02] Status www/gitlab@ee | gitlab-ee-17.10.3: = fetch-depends [00:05:46] [01] [00:00:02] Status www/gitlab@ee | gitlab-ee-17.10.3: = fetch [00:05:56] [01] [00:00:12] Status www/gitlab@ee | gitlab-ee-17.10.3: = checksum [00:05:56] [01] [00:00:12] Status www/gitlab@ee | gitlab-ee-17.10.3: = extract-depends [00:08:25] [01] [00:02:41] Status www/gitlab@ee | gitlab-ee-17.10.3: = extract [00:08:34] [01] [00:02:50] Status www/gitlab@ee | gitlab-ee-17.10.3: = patch-depends [00:08:34] [01] [00:02:50] Status www/gitlab@ee | gitlab-ee-17.10.3: = patch [00:08:34] [01] [00:02:50] Status www/gitlab@ee | gitlab-ee-17.10.3: = build-depends [00:27:47] [01] [00:22:03] Status www/gitlab@ee | gitlab-ee-17.10.3: = lib-depends [00:27:47] [01] [00:22:03] Status www/gitlab@ee | gitlab-ee-17.10.3: = configure [00:27:48] [01] [00:22:04] Status www/gitlab@ee | gitlab-ee-17.10.3: = build [00:27:48] [01] [00:22:04] Status www/gitlab@ee | gitlab-ee-17.10.3: = run-depends [00:27:48] [01] [00:22:04] Status www/gitlab@ee | gitlab-ee-17.10.3: = stage [00:27:53] [01] [00:22:09] Status www/gitlab@ee | gitlab-ee-17.10.3: = package [00:29:40] [01] [00:23:56] Finished www/gitlab@ee | gitlab-ee-17.10.3: = Success So, somewhat over 19 min build-depends -> lib-depends. After reboot: [00:05:58] [01] [00:00:00] Building www/gitlab@ee | gitlab-ee-17.10.3 [00:05:59] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = check-sanity [00:05:59] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = pkg-depends [00:05:59] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = fetch-depends [00:05:59] [01] [00:00:01] Status www/gitlab@ee | gitlab-ee-17.10.3: = fetch [00:06:06] [01] [00:00:08] Status www/gitlab@ee | gitlab-ee-17.10.3: = checksum [00:06:06] [01] [00:00:08] Status www/gitlab@ee | gitlab-ee-17.10.3: = extract-depends [00:09:37] [01] [00:03:39] Status www/gitlab@ee | gitlab-ee-17.10.3: = extract [00:09:46] [01] [00:03:48] Status www/gitlab@ee | gitlab-ee-17.10.3: = patch-depends [00:09:46] [01] [00:03:48] Status www/gitlab@ee | gitlab-ee-17.10.3: = patch [00:09:46] [01] [00:03:48] Status www/gitlab@ee | gitlab-ee-17.10.3: = build-depends [00:26:31] [01] [00:20:33] Status www/gitlab@ee | gitlab-ee-17.10.3: = lib-depends [00:26:31] [01] [00:20:33] Status www/gitlab@ee | gitlab-ee-17.10.3: = configure [00:26:31] [01] [00:20:33] Status www/gitlab@ee | gitlab-ee-17.10.3: = build [00:26:31] [01] [00:20:33] Status www/gitlab@ee | gitlab-ee-17.10.3: = run-depends [00:26:32] [01] [00:20:34] Status www/gitlab@ee | gitlab-ee-17.10.3: = stage [00:26:37] [01] [00:20:39] Status www/gitlab@ee | gitlab-ee-17.10.3: = package [00:28:07] [01] [00:22:09] Finished www/gitlab@ee | gitlab-ee-17.10.3: = Success So, somewhat over 16 min build-depends -> lib-depends. So, say, around 18 min for both before reboot and after it. Reproducible for general timescale. During the earlier "bulk -a" www/gitlab@ee got: [1D:19:47:18] [07] [00:00:00] Building www/gitlab@ee | = gitlab-ee-17.10.3 [1D:19:47:19] [07] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: check-sanity [1D:19:47:19] [07] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: pkg-depends [1D:19:47:20] [07] [00:00:02] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch-depends [1D:19:47:20] [07] [00:00:02] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch [1D:19:47:25] [07] [00:00:07] Status www/gitlab@ee | = gitlab-ee-17.10.3: checksum [1D:19:47:25] [07] [00:00:07] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract-depends [1D:19:48:19] [07] [00:01:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract [1D:19:48:50] [07] [00:01:32] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch-depends [1D:19:48:50] [07] [00:01:32] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch [1D:19:48:50] [07] [00:01:32] Status www/gitlab@ee | = gitlab-ee-17.10.3: build-depends [1D:21:11:47] [07] [01:24:29] Status www/gitlab@ee | = gitlab-ee-17.10.3: lib-depends [1D:21:11:47] [07] [01:24:29] Status www/gitlab@ee | = gitlab-ee-17.10.3: configure [1D:21:11:48] [07] [01:24:30] Status www/gitlab@ee | = gitlab-ee-17.10.3: build [1D:21:11:48] [07] [01:24:30] Status www/gitlab@ee | = gitlab-ee-17.10.3: run-depends [1D:21:11:50] [07] [01:24:32] Status www/gitlab@ee | = gitlab-ee-17.10.3: stage [1D:21:11:57] [07] [01:24:39] Status www/gitlab@ee | = gitlab-ee-17.10.3: package [1D:21:16:11] [07] [01:28:53] Finished www/gitlab@ee | = gitlab-ee-17.10.3: Success where the load averages were near the FreeBSD cpu count over the time frame. So, it appears that competing for I/O bandwidth with the other builders makes the difference of: around 18 min vs. around 83 min for build-depends -> lib-depends . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Apr 15 06:27:31 2025 X-Original-To: freebsd-current@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 4ZcDjK24mCz5t2kQ; Tue, 15 Apr 2025 06:27:33 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZcDjK1R05z3GhL; Tue, 15 Apr 2025 06:27:33 +0000 (UTC) (envelope-from cperciva@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744698453; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:autocrypt:autocrypt; bh=XtMzF0axQUWIT56sW1L1+ii9D8zGcKWf9vkCvy+tl70=; b=ykyJyDMK18o25NtIK7cux0Gpo1GfERmIvxpXuhaugTqg2+81Xku7k9wE6fJJjNSuDIZxmP BWpPu9xMJRotRKer9G7Ln208wwHN7lOzoOYE5RkxfQ4M4WYJn0p/OmyXrJuwq/xyMBtRUL Fie0eGk98w+U/dvPSokYaU50DmO0/Gf4n8cbZD2KfhCqjwMOKevpoMi7UUzI0+tLZYMwFu 1xmXU1sdRYC5z78liGMaqDsFnpxWRnkyWCR+ljCgfhM9vBIBPPU0aCLy4BKVnGm/mBv+lU xbByMDGKmyPl2iv6EzkxuYwdvt4bKKEZ7TM64a9SBo3qac2tii791ORpyJoMCA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744698453; a=rsa-sha256; cv=none; b=MX+hqUUphyXvt337sYuMZLWqXZ8Qu0GgQHmbaKAe+BKsZCVYZcT9mIZjDKqeF3CIvY0VNr Y1VaHuCd87vcd+VhO9Q8nc19mIqR34/MBkxIZ4aYcCcR9Q0YJQ0076xhAcRvUSSBnOx0+/ LyYEDC9qv2KmrKRsZ6rNce3dkmucTZJ9DWxJv81/lnhdHMHfjHEiIpAMgNUEbxaTL2w99C ZrOFnd8fCYSNnANt/wa9pu4RLay13dxxTdhDi4ctOpl1nVMB9ccTJWbWZ0bUB3reTG4/1Z Um43U0d6ew7b4vecNW0yHudZzQrQayjcdx2oVFFHAfqJMjOKOUPiVj67ueibAQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744698453; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:autocrypt:autocrypt; bh=XtMzF0axQUWIT56sW1L1+ii9D8zGcKWf9vkCvy+tl70=; b=GQhoGGg26V7+RekDiVeMtj4ocCKQ/fz5ukeLlEhqiyQrSKmEc6RdnLsk7Td8w/nxcq5rfS mAcA6u1j3Rx/yTai34HnXyK9Jx6HiTRnPvGXr4uvoKPPfXvsNEKii/FIHPoyNwJ/Z78qkj zC9dKyptZsSI/tszwaHz9V0tuHVNXLs6P9jRnuHtRIS5OEM9OZ8ziwuS6mc9pN5s8rgQ8l 6RVyElyrdlvDSrUAjNZ6LWnvN7Iqu8ZOAfJUI3x9Mbv/weNTjNXHlRIGlfHI66mthnaDAr u1fujMlDAvK2P0ZhTkTZHiutE+cHS0OT4jbA3BXhz7zluDwPPId2e3OBNWAHPg== Received: from [192.168.6.36] (S0106684a76304d01.vf.shawcable.net [70.69.240.84]) (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) (Authenticated sender: cperciva/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZcDjJ4ytQzTk; Tue, 15 Apr 2025 06:27:32 +0000 (UTC) (envelope-from cperciva@freebsd.org) Message-ID: <243f5125-ea10-41ed-97f8-db9770f9990c@freebsd.org> Date: Mon, 14 Apr 2025 23:27:31 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Colin Percival Subject: 15.0-RELEASE schedule To: FreeBSD Stable , "freebsd-current@freebsd.org" Cc: FreeBSD Release Engineering Team Content-Language: en-US Autocrypt: addr=cperciva@freebsd.org; keydata= xsFNBGWMSrYBEACdWRqDn3B3SKO7IG0/fGHYtfs26f3Q5QeAcasy1fQLniwGQWn5rlILhbCD K/jdNoDm5Zxq20eqyffoDNObCjnHgg4tGANdi+RmDy+7CDpE789H8dss9y7Pt5DlGGAXQQnt hxush3EYS/Ctprd9UUL/lzOOLOU1aNtzB84tNrJBtcJmL7OYHfyTSNFxvedqJrrasejIQOLI t/DQ89BPzz+vsKHz7FJPXh3fsVkzLA00DJYcfkgxyABfJNA7U6yMwd4DVSdx/SsvfIDMVXnu UXCXswo106WPZbYGlZPpq0wW6iibtTerJix+8AeuwXvl9O1p8yESK4ErkIxCnmghTSz+pdzj z/6xBRkdDM9VdZ0r+CzsaNXMpDOzFuKyjaiYBdgCLljbDnXIHFcqXenrZ7Xwkm09g/M4uVSh pIUG2RYa6tsHSQoGCp3f2RZv1znfViKQFbbL83QjtPA20AhseZSYbHp1FPhXyy9J0wkGL16L e99g6gdGeIRE82BZjBjKGDkoyDPq+oDRSFl8NtzmIKy+cfz00nViqcTF4bREXEawFGhlpO0X O9q8mijI9iFB6zaPBiSdJGBL5ML5qLTNCl8Zlf4m1TBvmRTqF/lzMHVXHidDoUhpSh/y3AFZ 1KrYc27ztJQywDJPJPWPbtY8YhFLFs377gfP8WldsZjzp8nvoQARAQABzSVDb2xpbiBQZXJj aXZhbCA8Y3BlcmNpdmFARnJlZUJTRC5vcmc+wsGRBBMBCAA7FiEEglY7hNBiDtwN+4ZBOJfy 4i5lrT8FAmWMSrYCGwMICwkNCAwHCwMFFQoJCAsFFgMCAQACHgUCF4AACgkQOJfy4i5lrT++ ig/9GZKdN2fHSyrANKZX38ivd7IX2wAYouqH9DrQM94W8IciaDLmarN4Pl9mY+aucMwQUSyp uNtKOJwKqhVVaalF9Zw0sRMH4CJuvT7vKCtZ3q1Okb7soRvFte4d+vXhvPxCvBFDA5JzU7Lg DR5eqqcvF1dN1OuCq16pl0zCOSH/Jr5ToE3LM3Av1KBGcZD7ZSzHRWsFjV5AOUJKySuA3GwJ e/jASQcQ0YfCnru8ntLmYg/2SKvZFlfthZiCBnAppMt4n4BUAw3TDvf10HIDtdneejawcbLS gofLCvGqumwbZYAMKWrFzT4+7KQvr0pOw8QD7EbxnB4f9hQ7UiVF8qWsyKU3iv6b5JLhbS59 ooKRccyOvdMLcVJ0ZdpqoxrNv061ZUqLL5RiWjBlc1qjBnDxeg5oyM0rT8WLftdgvyH6RQt0 KWngumBAT5AT2DUYL8Uz1490cqfO9K4yEGZAJB9XRVX1g2IWTOjae+0g9ZII+h91UngFz+Rz aKDeseKBbCGDOFXx1TqKiHl2g255ZnUxKYTlucFtguv4gDGBgEk4G9JaEWBw1IWblcKhxH7L 2vWsUhvwghjIxHdO/RkeIeHvSp4YZxCJ7a3TaJLYAlwYopfTKVzNhcDY5h5syEuoHjyJCxXK SyoJYAVu8Yl2KUhvOtOmL1VZ6xyHnpdMRWKJZ5jOwU0EZYxKtgEQANYfgbtUMVnhjxDHhWLp g5kLHK3YW0TfJKzpXqDB7NiqxHofn4OcbZnVC3MKggcbs9o1/UtsjnlsG8550PfiYkDXvPiO RJwgbGs6MGIDK797C6cnBLQ8xwBa9SL4cl5iQFnhWmt6vwnJ+an/cm5JpYves3wL7jV09qU9 57hkHXEUcl38r4FssZzVcLKPUVTa3Un+QGRTGDGe/f4ctjMaqv0ZCM+l2ixPhf/vqESrfSLv V/+T3dmtUfXjazO3SABvsHwxgGuTTYOlKoPCaebr+BRdqm0xeIShoIlhvTI8y4clchqx/Uxg UG5X2kvU13k3DS3Q8uLE4Et9x1CcZT6WGgBZSR6R0WfD0SDnzufNnRWJ0dEPA2MtJHE7+85R Vi9j/IgZV+y5Ur+bnPkjDG1s2SVciX5v9HQ0oilcBhvx0j5lGE9hhurD9F+fCvkr4KdbCknE 6Y8ce8pCNBUoB/DqibJivOzTk9K9MGB5x0De5TerIrFiaw3/mQC9nGeO9dtE7wvDJetWeoTq 4BEaCzpufNqbkpOaTQILr4V6Gp7M6v97g83TVAwZntz/q8ptwuKQPZ2JaSFLZn7oWUpYXA5s +SIODFHLn6iMoYpBQskHQjnj4lEPJadl4qj+ZKA89iDAKsniyoFXsbJe2CPbMS1yzBxKZq6K D/jpt7BOnuHr/JrXABEBAAHCwXYEGAEIACAWIQSCVjuE0GIO3A37hkE4l/LiLmWtPwUCZYxK tgIbDAAKCRA4l/LiLmWtP3jmEACQrh9gWe8F1Tkw3m6VoHKwLc5he4tX3WpQa//soPO6iGG3 S3WPruQ46NrAaAojoOcKI9UONDO5rxG0ZTX53S+lu2EO47jbcLwOCjaEpjKpDRt9ZXBQE8Xl mtBE9Bp3W9gpjB1nE3KNM1mJYgsK0QdRpwwfh4pVgGpOj8j23I6MCK+v99zEBnpgCn2GX8W/ kctRXHqWwndHysOJtRP/zrl7dDaABF1f9efUl0LL3TD3GJ9VDz+DNOin/uK2a1hiJo8QzTRk PpfUQ2ebzDsrd1i/pOWkMSkdH+rEu4AGrXWtaBwrMyrGkL6Icb6yO+P9/z0W2wlgBf3P1YRt JPgQt/Dj3yvA/UnaV/QmuVQPjl13o24UnJGsZM8XGnNdfWBKkC1Q6VXC4QT+dyBHYH9MuE9d 6oGl8pFM1+cTfEfbM62/rRoPkF1yHMsI/903VxEvuUIKfhEZAVLFyHldooNxuchntHQP9y8J 8Ou9bWYQP7MnEn+kwSwrZkjurfPkan+xQvp6dDYnj3V0GwA5pprBMaB928VIDVOv+1PNQI3t Cvk5VPv/skq+TJRMHW7bFSt8PRa91cUf1FOLIz9APDiJOzXkwxUEHGV3zPSaUhs1JYjyBeGT wDAvtLUdjOnRhEUOwlnIrztmvyciutjJoVzKEEjj5WXnHk9L9kQ1bpAjkjTONw== Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi FreeBSD users, I've just posted the schedule for FreeBSD 15.0 to the FreeBSD website. As a .0 release, this release cycle will be lengthier than normal, spreading over the last half of 2025. 15.0-RELEASE schedule: reminder email: July 11, 2025 main slush: August 8, 2025 stable/15 branch: September 5, 2025 ALPHA builds start: September 5, 2025 ports quarterly branch: October 1, 2025 releng/15.0 branch: October 3, 2025 BETA builds start: October 3, 2025 doc/ tree slush: October 3, 2025 doc/ tree tag: October 17, 2025 ports package builds: TBD (Between October 17 and 30[*]) RC builds start: October 31, 2025 RELEASE build starts: November 28 or sooner, 2025 RELEASE announcement: December 2 or sooner, 2025 15.0-RELEASE EoL: September 30, 2026 Branch EoL: December 31, 2029 [*] Or later depending on schedule slippage. I haven't listed all of the builds but they'll be a week apart per normal practice. In short: * Instead of 2 weeks of "reminder" I'm scheduling 4 weeks. * Instead of 2 weeks of "slush" I'm scheduling 4 weeks. * The stable branch happens on the first Friday of September. * There will be 4 ALPHAs built from stable/15 before the releng branch. * Instead of 3 BETAs I'm scheduling 4 BETAs. * Instead of 1 RC I'm allowing time for 4 RCs (although less would be nice). I think this allows enough time for problems to arise and be fixed without the schedule slipping; in particular allowing 4 weeks for RCs essentially means we have 3 weeks of schedule slippage built in, while a predicted release date of December 2nd means that in the worst case we can have 4 more weeks of delays before we run past the end of the quarter. -- Colin Percival FreeBSD Release Engineering Lead & EC2 platform maintainer Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From nobody Tue Apr 15 10:17:26 2025 X-Original-To: freebsd-current@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 4ZcKpx3Rvjz5srgD for ; Tue, 15 Apr 2025 10:17:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4ZcKpw5tdcz3hxM for ; Tue, 15 Apr 2025 10:17:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jjtpKWAf; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744712258; bh=3M98rrEwnUdJCiNLwS2JWcZNTCr4UdqKFWnX7fahkRQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jjtpKWAfA2MVuDkyPfWO60nkRbtcZgsNmq9Bm1TsQ92tYOlDpKjP/7/s1TLxci9vh+eUW3IuOdfM6eXhyEMszNCBDUgnQq9nxmHKqS/ajMIj7CF3hs2NeFpeTEdsbZ7D6pyH89ZqX1k1JI05fGKfMBzzgNGCnH8EZQtkdJFOIIqWL4Iil4kDEPjz2buW/ZpARiTwJ8eZO8o0d8uJl1UmVAN1NIznibq1p3hMlrcv7B4s1JPVPPl++NpygvGqwXzfNT8EkPsgSNtAhtCnY40qXIgIIFhlsaoU486rctMNtrGhL52ddxBQmNYHpc7Z+t+iTjuQOj+3Hg0y/VG1RQK/9Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744712258; bh=b8oHWVrw+8cj3f7wdNrXvSBckI0zZFPJ/om2z9tTyk6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=FFjmzdu3vb8cQsEux9Sd85Z4QTl8PA1fH10ZAySfz5uG08CxlQwtASrkeMP+fhTUB7jLbPNXmvfLn4rFZnErSyq9pkaohGhAIfr9M26IHG46BkbIdKqL7r3YfrUkwrdz/Msbb7BWxm44Rsggf9nRQMkX0+A8tgmZ/a7DSUbXK30TkYGUXa1OnypUVqLXQo394j2ErpukQAeo/CqApp7GGvp+uX8RPkEYKEpoynQJKCaSUSdPmr+8WjxJdosiAs8QrqYrtQeniQdcYRsf9G5skzL6WBiXJyZ+dZp50KXKgXMyasByb3dBFbGTCeoDJWyz+XgBgxdA7RplC3Mw+qIRFQ== X-YMail-OSG: qJia4lcVM1kuUnB0cgD2R6SohJ7u13HPbZKP4nug1Lh1d7if.MFastcpgyJne6Z vyInIZ8Kq_C2DA_JacTkXi2Tc_mXohhHKlnYNLeQR84swVRWmIIFTva2_GUJnCajsf_fSwKLkRNp 8GNutaSay0.8RCuwPYyB7FXEarP6y2T.DcVDeqBh.yGxAuVu8r9PXwHdmmJoMZ7O2s6KMB1XqQPI 7HoCLELDE8.jtiCNQALPBzlN5EKhnAijJlvnSVTQ3t0JMzdnkF8m.IlE_68SAiDkyO5ACqadwz5R jJo9CUGNiSg516yiX_6rxmsF8Z6T68cDEze_LZEgZ7AQEW76o89rBoq7H5y1ctPTDaNWRkwlcl0V DDXmS6NL427LVGoTXksr3Ko7HfNlRf35FtpKtSeVtFRZ098JNhc3rn07RMnyLukbqDD.6mkYBdYH dyP_4g1ewjPCRYQh45_XU14Z6SFVOdsxJeE8WtGa0kQlU0hWkBa8VvKhXRhpRifD5VrC2REElBie 3LP8vPePaF4LXC8iDfkKuyCvArz8x0d82iJ5CJMQcWCfm4xfdLYP81W8orRA.6fy67Xvc8HLssoo FWt1ls.KqJIsybH.29JywQAejKbSImmPhgiVnYEaRXXHIAWPl2o9c9FIEjgcA7a4KMmflxGOGmBY RB090bcVk54Ucx10ijw6AJqchW.CNXvwowkRosrcqnvPbUtoR9YhqZ.IWnq3VJ1NDmecIFSLkwto rg00.jMut0ogvFHE35s3ZmurCptxVzmiuD5JffFQNFSXcoVdpiLu7XsLTucmt04J8zv5X8PTNuNU jixwsdvdcVsLX1Zl6UNvF4fzvVz7LtzOpRorFSSXBJ9A396yOTtv0fiA5DTK7S3YK4HOVIiU31_a zbLXQKFM0THgoDx1FrhKuQjC8.C8WTyvSNM877IPdZFf9TugistSYAgqv0gV.d.c7HLxjB19T.Q4 CubalPn8X7xGd_o7gZueJitKT.Izgew8Dh9Emax5wn7xkaCreUatDLucNnrnSmBZUbClee1elq2y s8jM5kBjTHEspLkJoUkMIyJVL5V2LNtPiz01RKcLzkv7X97TVulSZpiuX6WS3xVCKIQGyHTUxss9 rpi73SY64JIZ3xcYtlWqQFmYakcpuNrqN2ZeevaV387ALO53V7mtlt3govKQaDU2kSYGTViTsqos DMZeWMMBS8Rd00w1Q5By3ldKn7636gY6FnUea1MTkTUrfztGZ2hLgT1zrxLsLMok0vDEmvnaILdA .4V7.QopX6T2Wi.yythhk6hnxKcsIzVYi3jj9pLv8Q.k4lgJp0wJW2.z2.ejKpRSi5Vdbx8oK.uu BgGPkbNtC61t3lJNKI8r0_0.GJKAwO4ooXLzz1ptwrlB6YScPPrqD3HbC9vgwB6LeneKiJPm6JAL lTukRCHnoYmXmuwcgVm754VM6KK5AfIYV4BGFcVP4LCica7ypxZkSsg8WI8zAJvoj9YNFn.pjYPP yCsJdOXIqlRF_5I4jMoiFuBVSRALczjmonUNPXgLo9dn0AUcfAGuAH_Bu9HrOi9N8wA5HBcGM9wp 5.vbu01ms3XMISzrEXNNFg0s92YnyDbNAqOYb5ijN_SeJSS04bdGGCr_ZjUz01_tUVnD3SzWAa9v z6viM1GH2.d3SmvLchzsmHqCmyuOI96U76GQHw7dXvD7UhKZ.Q9GVNMPO2sSlqyKellOXS6jOrSj 0lGCIaMYZuSuBQHbs05d.Z1BODoWj2gB14mjzsi.CAKfB4Ox9Z0H1Rumun.F3BShvQQg11s1mKtm gI478DMHsaZy1wHVtn_nEvkwpTLgVvnQtQeehLnceRRZ7j3tFNJlnW9b7LY881Le3j6H3uB7gVSG HaZIZRks6OmZQwt9aEEmYQCNxnsxwYljy4PewIB5zUcd5PdagW0ljbF8VDz8MaaC5.4xxONw_fz8 qJV5tu1AJvcqqTeWHdwy0tCncvgbTtT6G5zYeGFpEb9LliphC7OzFijitNBXyiT_xpLVxPvhgjEK 0xv0n3hPmSG2mMDp66tjx7SWaXZDDFRdTscGq3FSQJmccCF.OelIVA63GSEZ_h.XOF6dRqaBAFI1 5lA03YIQnGMZ6of.tDBF2qazPs8oUh96h7Lph9YSCOf4AIPbjQ0NEMLwbjQ6Sfm4mEUwY6PeptxE S3bndfH_TP8uAEoEnij9DcRbIt_wGHhTDpThJPen9qSjc7EyPQ3r1gSBCH7Xg.NVihfEn7clhdjO eVwsnWvPH1rX08r6vvkfrj7BqzN1W1OFAwemtTSCnO.TULy.DdwKMTf2SWx41SGlwrt7xl3IJ9sE mKizD X-Sonic-MF: X-Sonic-ID: 2cf9d635-59bf-4281-917f-60f087c9e937 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 15 Apr 2025 10:17:38 +0000 Received: by hermes--production-gq1-74d64bb7d7-fsgc5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d4444aae4ef9ed293871effc102c749e; Tue, 15 Apr 2025 10:17:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes] From: Mark Millard In-Reply-To: <8308705D-5155-48B2-ADFC-2BCF32F7D55C@yahoo.com> Date: Tue, 15 Apr 2025 03:17:26 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <8B070D1D-0524-4DA4-A5C2-EF2CF98C5E15@yahoo.com> <7A1322FA-A118-4F87-9D96-DE8B05E09424@yahoo.com> <6C67E39F-3634-4AF6-95EC-46159E7391E5@yahoo.com> <8308705D-5155-48B2-ADFC-2BCF32F7D55C@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-2.65 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.86)[-0.862]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_MEDIUM(-0.29)[-0.295]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RBL_SENDERSCORE_REPUT_8(0.00)[98.137.68.204:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4ZcKpw5tdcz3hxM X-Spamd-Bar: -- On Apr 14, 2025, at 16:43, Mark Millard wrote: > On Apr 11, 2025, at 23:55, Mark Millard wrote: >=20 >> On Apr 11, 2025, at 19:28, Mark Millard wrote: >>>=20 >>>> . . . >>>>=20 >>> . . . >>>=20 >>=20 >> . . . >>=20 >>>=20 >>>=20 >>> Back to the originally intended content . . . >>>=20 >>>=20 >>> On Apr 11, 2025, at 14:04, Mark Millard wrote: >>>>=20 >>>> On Apr 11, 2025, at 11:39, Mark Millard wrote: >>>>=20 >>>>> On Apr 7, 2025, at 08:14, Baptiste Daroussin = wrote: >>>>>=20 >>>>>> . . . >>>>>> the problem we have is the >>>>>> performance changes depending on what is happening in parallel on = the machines. >>>>>=20 >>>>> In separate list messages I've provided multiple examples >>>>> of the time-taking issue that do not depend on what is >>>>> running in parallel on the machines, no parallel builds >>>>> involved. >>>>>=20 >>>>> Part of the issue is that there are thousands of examples of >>>>> "small build-step time" packages for which the build-depends, >>>>> lib-depends, run-depends combination, takes notable time, >>>>> given that the total time contribution across those thousands >>>>> of package builds is notable overall. >>>>>=20 >>>>> As stands, mostly it is the early part of "bulk -c -a" avoids >>>>> the issue via building packages that have no or few >>>>> dependencies. Later "small build-step time" packages tend to >>>>> have various dependencies, greatly changing the time scale >>>>> for their builds. Few builds are of "large build-step >>>>> time" packages (relative to there being 30000+ packages). That=20 >>>>> has implications for there being 30000+ packages to build for >>>>> "bulk -c -a" or other builds with large numbers of packages >>>>> to try to build. >>>>>=20 >>>>>> which makes the performance issues invisible on local poudriere = if you want to >>>>>> test it on port A or port B, >>>>>=20 >>>>> I've provided counter examples to that that only involve the >>>>> one builder, after the prerequisites have already been built >>>>> (same or prior bulk run). >>>>>=20 >>>>>> if we want to reduce the performance penalty we >>>>>> need to be able to make a reproducible case which can then be = profiled, to know >>>>>> where to optimize if needed. >>>>>=20 >>>>> I've provided examples of such . . . >>>>> (time intervals shown are from the aarch64 >>>>> Windows Dev Kit 2023 with just the one >>>>> builder active) >>>>>=20 >>>>> www/rt50 >>>>> build-depends: 00:00:27->00:08:46 >>>=20 >>> More detailed comparison/contrast of non-parallel builds: >>>=20 >>> A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >>>=20 >>> [00:01:11] [01] [00:00:00] Building www/rt50 | rt50-5.0.7 >>> [00:01:14] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = check-sanity >>> [00:01:14] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = pkg-depends >>> [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = fetch-depends >>> [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: fetch >>> [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = checksum >>> [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = extract-depends >>> [00:01:15] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: extract >>> [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: = patch-depends >>> [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: patch >>> [00:01:16] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: = build-depends >>> [00:01:24] [01] [00:00:13] Status www/rt50 | rt50-5.0.7: = lib-depends >>> [00:01:24] [01] [00:00:13] Status www/rt50 | rt50-5.0.7: = configure >>> [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: build >>> [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: = run-depends >>> [00:01:26] [01] [00:00:15] Status www/rt50 | rt50-5.0.7: stage >>> [00:01:29] [01] [00:00:18] Status www/rt50 | rt50-5.0.7: package >>> [00:01:50] [01] [00:00:39] Finished www/rt50 | rt50-5.0.7: Success >>>=20 >>> A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >>>=20 >>> [00:03:04] [06] [00:00:00] Building www/rt50 | rt50-5.0.7 >>> [00:03:06] [06] [00:00:02] Status www/rt50 | rt50-5.0.7: = check-sanity >>> [00:03:06] [06] [00:00:02] Status www/rt50 | rt50-5.0.7: = pkg-depends >>> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = fetch-depends >>> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: fetch >>> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = checksum >>> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = extract-depends >>> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: extract >>> [00:03:07] [06] [00:00:03] Status www/rt50 | rt50-5.0.7: = patch-depends >>> [00:03:08] [06] [00:00:04] Status www/rt50 | rt50-5.0.7: patch >>> [00:03:08] [06] [00:00:04] Status www/rt50 | rt50-5.0.7: = build-depends >>> [00:16:26] [06] [00:13:22] Status www/rt50 | rt50-5.0.7: = lib-depends >>> [00:16:26] [06] [00:13:22] Status www/rt50 | rt50-5.0.7: = configure >>> [00:16:27] [06] [00:13:23] Status www/rt50 | rt50-5.0.7: build >>> [00:16:27] [06] [00:13:23] Status www/rt50 | rt50-5.0.7: = run-depends >>> [00:16:28] [06] [00:13:24] Status www/rt50 | rt50-5.0.7: stage >>> [00:16:30] [06] [00:13:26] Status www/rt50 | rt50-5.0.7: package >>> [00:17:03] [06] [00:13:59] Finished www/rt50 | rt50-5.0.7: Success >>>=20 >>> (That I got the 00:13:22 is interesting, given the prior >>> 00:08:46. May be the A78C cores were used instead of the >>> X1C cores? May be that there were no builds, just Inspecting >>> activity for the prerequisites. Did I not match the USE_TMPFS >>> settings? I expect that the general structural conclusions >>> are not invalidated.) >>>=20 >>>>> devel/py-inline-snapshot@py311 >>>>> build-depends: 00:00:01->00:00:55 >>>>> run-depends: 00:00:56->00:01:47 >>>=20 >>> A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >>>=20 >>> [00:00:54] [04] [00:00:00] Building devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1 >>> [00:00:54] [04] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.18.1 >>> [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: check-sanity >>> [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: pkg-depends >>> [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: fetch-depends >>> [00:00:59] [04] [00:00:05] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: fetch >>> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: checksum >>> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: extract-depends >>> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: extract >>> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: patch-depends >>> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: patch >>> [00:01:00] [04] [00:00:06] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: build-depends >>> [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: lib-depends >>> [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: configure >>> [00:01:01] [04] [00:00:07] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: build >>> [00:01:02] [04] [00:00:08] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: run-depends >>> [00:01:03] [04] [00:00:09] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: stage >>> [00:01:03] [04] [00:00:09] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: package >>> [00:01:04] [04] [00:00:10] Finished devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.18.1: Success >>>=20 >>> A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >>>=20 >>> [00:02:46] [02] [00:00:00] Building devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8 >>> [00:02:46] [02] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 >>> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: check-sanity >>> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: pkg-depends >>> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: fetch-depends >>> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: fetch >>> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: checksum >>> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: extract-depends >>> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: extract >>> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch-depends >>> [00:02:47] [02] [00:00:01] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: patch >>> [00:02:48] [02] [00:00:02] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build-depends >>> [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: lib-depends >>> [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: configure >>> [00:03:59] [02] [00:01:13] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: build >>> [00:04:00] [02] [00:01:14] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: run-depends >>> [00:05:27] [02] [00:02:41] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: stage >>> [00:05:28] [02] [00:02:42] Status devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: package >>> [00:05:28] [02] [00:02:42] Finished devel/py-inline-snapshot@py311 = | py311-inline-snapshot-0.20.8: Success >>>=20 >>> (Again longer 2.1.0 times vs. previous 2.1.0 times.) >>>=20 >>>>>=20 >>>>> mail/mailest@nox >>>>> build-depends: 00:00:01->00:00:28 >>>>> run-depends: 00:00:30->00:00:59 >>>=20 >>> A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >>>=20 >>> [00:00:58] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 >>> [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity >>> [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends >>> [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends >>> [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch >>> [00:00:59] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum >>> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends >>> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract >>> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends >>> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch >>> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends >>> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends >>> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure >>> [00:01:00] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build >>> [00:01:03] [01] [00:00:05] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends >>> [00:01:08] [01] [00:00:10] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage >>> [00:01:09] [01] [00:00:11] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package >>> [00:01:09] [01] [00:00:11] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >>>=20 >>> A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >>>=20 >>> [00:02:50] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 >>> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity >>> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends >>> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends >>> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch >>> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum >>> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends >>> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract >>> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends >>> [00:02:51] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch >>> [00:02:52] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends >>> [00:02:52] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends >>> [00:03:31] [01] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure >>> [00:03:31] [01] [00:00:41] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build >>> [00:03:32] [01] [00:00:42] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends >>> [00:04:08] [01] [00:01:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage >>> [00:04:08] [01] [00:01:18] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package >>> [00:04:09] [01] [00:01:19] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success >>>=20 >>> (Again longer 2.1.0 times vs. previous 2.1.0 times.) >>>=20 >>>>>=20 >>>>> devel/dwarves >>>>> build-depends: 00:00:05->00:02:23 >>>>> lib-depends: 00:02:23->00:02:42 >>>=20 >>> A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >>>=20 >>> [00:00:56] [07] [00:00:00] Building devel/dwarves | dwarves-1.19_3 >>> [00:01:01] [07] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: check-sanity >>> [00:01:01] [07] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: pkg-depends >>> [00:01:01] [07] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: fetch-depends >>> [00:01:01] [07] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: fetch >>> [00:01:01] [07] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: checksum >>> [00:01:01] [07] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: extract-depends >>> [00:01:01] [07] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: extract >>> [00:01:02] [07] [00:00:06] Status devel/dwarves | = dwarves-1.19_3: patch-depends >>> [00:01:02] [07] [00:00:06] Status devel/dwarves | = dwarves-1.19_3: patch >>> [00:01:02] [07] [00:00:06] Status devel/dwarves | = dwarves-1.19_3: build-depends >>> [00:01:07] [07] [00:00:11] Status devel/dwarves | = dwarves-1.19_3: lib-depends >>> [00:01:08] [07] [00:00:12] Status devel/dwarves | = dwarves-1.19_3: configure >>> [00:01:08] [07] [00:00:12] Status devel/dwarves | = dwarves-1.19_3: build >>> [00:01:13] [07] [00:00:17] Status devel/dwarves | = dwarves-1.19_3: run-depends >>> [00:01:13] [07] [00:00:17] Status devel/dwarves | = dwarves-1.19_3: stage >>> [00:01:13] [07] [00:00:17] Status devel/dwarves | = dwarves-1.19_3: package >>> [00:01:14] [07] [00:00:18] Finished devel/dwarves | = dwarves-1.19_3: Success >>>=20 >>> A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >>>=20 >>> [00:02:54] [05] [00:00:00] Building devel/dwarves | dwarves-1.19_3 >>> [00:02:58] [05] [00:00:04] Status devel/dwarves | = dwarves-1.19_3: check-sanity >>> [00:02:58] [05] [00:00:04] Status devel/dwarves | = dwarves-1.19_3: pkg-depends >>> [00:02:59] [05] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: fetch-depends >>> [00:02:59] [05] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: fetch >>> [00:02:59] [05] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: checksum >>> [00:02:59] [05] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: extract-depends >>> [00:02:59] [05] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: extract >>> [00:02:59] [05] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: patch-depends >>> [00:02:59] [05] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: patch >>> [00:02:59] [05] [00:00:05] Status devel/dwarves | = dwarves-1.19_3: build-depends >>> [00:05:33] [05] [00:02:39] Status devel/dwarves | = dwarves-1.19_3: lib-depends >>> [00:06:07] [05] [00:03:13] Status devel/dwarves | = dwarves-1.19_3: configure >>> [00:06:07] [05] [00:03:13] Status devel/dwarves | = dwarves-1.19_3: build >>> [00:06:12] [05] [00:03:18] Status devel/dwarves | = dwarves-1.19_3: run-depends >>> [00:06:12] [05] [00:03:18] Status devel/dwarves | = dwarves-1.19_3: stage >>> [00:06:12] [05] [00:03:18] Status devel/dwarves | = dwarves-1.19_3: package >>> [00:06:12] [05] [00:03:18] Finished devel/dwarves | = dwarves-1.19_3: Success >>>=20 >>> (Again longer 2.1.0 times vs. previous 2.1.0 times.) >>>=20 >>>> net-mgmt/fastnetmon >>>> build-depends: 00:00:03->00:00:42 >>>> lib-depends: 00:00:42->00:01:29 >>>=20 >>> A pkg 2.0.6 vintage of ports tree on Windows Dev Kit 2023: >>>=20 >>> [00:01:00] [02] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 >>> [00:01:00] [02] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity >>> [00:01:00] [02] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends >>> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends >>> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch >>> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum >>> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends >>> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract >>> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends >>> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch >>> [00:01:01] [02] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends >>> [00:01:03] [02] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends >>> [00:01:07] [02] [00:00:07] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure >>> [00:01:10] [02] [00:00:10] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build >>> [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends >>> [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage >>> [00:03:15] [02] [00:02:15] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package >>> [00:03:18] [02] [00:02:18] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success >>>=20 >>> A pkg 2.1.0 vintage of ports tree on Windows Dev Kit 2023: >>>=20 >>> [00:02:54] [06] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 >>> [00:02:55] [06] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity >>> [00:02:55] [06] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends >>> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends >>> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch >>> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum >>> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends >>> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract >>> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends >>> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch >>> [00:02:56] [06] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends >>> [00:04:10] [06] [00:01:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends >>> [00:05:41] [06] [00:02:47] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure >>> [00:05:44] [06] [00:02:50] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build >>> [00:07:43] [06] [00:04:49] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends >>> [00:07:43] [06] [00:04:49] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage >>> [00:07:44] [06] [00:04:50] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package >>> [00:07:46] [06] [00:04:52] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success >>>=20 >>> (Again longer 2.1.0 times vs. previous 2.1.0 times.) >>>=20 >>>> (See later below.) >>>>=20 >>>>> The timings are from the column next to >>>>> the Building/Status/Finished column from >>>>> using bulk -v , not from the column for >>>>> the overall bulk run. >>>>>=20 >>>>>> I have tried to reproduce each individual case which happen in = the ports tree >>>>>> and I am not able to reproduce them, so impossible to know where = to look at >>>>>> exactly. >>>>>=20 >>>>> Try some of the examples that I've provided? >>>>>=20 >>>>> There are more examples that I could check >>>>> and report non-parallel timings on if you >>>>> want. I just picked to report on only a few >>>>> initially. >>>>>=20 >>>>> An example that you might want is my >>>>> providing more examples of lib-depends >>>>> with non-parallel timings. >>>>=20 >>>> I took a quick look and quickly ran into: >>>> (aarch64 Windows Dev Kit 2023 no-parallel-builders >>>> timing again, after having built the prerequisites >>>> that had not previously been built) >>>>=20 >>>> [00:11:37] [01] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 >>>> [00:11:39] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity >>>> [00:11:39] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends >>>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends >>>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch >>>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum >>>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends >>>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract >>>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends >>>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch >>>> [00:11:40] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends >>>> [00:12:19] [01] [00:00:42] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends >>>> [00:13:06] [01] [00:01:29] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure >>>> [00:13:09] [01] [00:01:32] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build >>>> [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends >>>> [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage >>>> [00:14:20] [01] [00:02:43] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package >>>> [00:14:22] [01] [00:02:45] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success >>>>=20 >>>> (I still have thousands of packages that have not built >>>> in the bulk -v -a build activity. The M4 MAX is in use >>>> for that.) >>>>=20 >>>>>> I know what is new and what causes the performance penalty, but = not >>>>>> which part is causing the super extra penalty on the cluster. >>>>>=20 >>>>> Various examples reproduce the timing issues >>>>> outside the cluster and without the parallel >>>>> builds. >=20 > These results are from the M4 MAX context for pkg 2.1.0 use. >=20 > I finished a "bulk -a" sequence (without having kldloaded linux = support). > So I can now do the likes of: >=20 > # poudriere bulk -jrelease-aarch64 -v -p alt -C www/gitlab@ee >=20 > without having to build the prerequisites. No parallel builds = involved. > For that specific example I'll do it once before rebooting and once > after, checking on caching effects. FYI: >=20 > [00:05:28] Building 285 packages using up to 12 builders >=20 > (But the prerequisites just get: > "Inspecting . . .: determining shlib requirements", no actual > builds.) >=20 > I'll not repeat that part below. >=20 > I'll also note that "Creating pkg repository" after such a > build seems to not be an incremental activity for the small > number of packages that change (1 here): >=20 > (before reboot case) > [00:29:41] Creating pkg repository > Creating repository in /tmp/packages: 100% > Packing files for repository: 100% > [01:34:32] Committing packages to repository: = /usr/local/poudriere/data/packages/release-aarch64-alt/.real_1744660767 = via .latest symlink >=20 > (after reboot case) >=20 > [00:28:08] Creating pkg repository > Creating repository in /tmp/packages: 100% > Packing files for repository: 100% > [01:29:53] Committing packages to repository: = /usr/local/poudriere/data/packages/release-aarch64-alt/.real_1744668230 = via .latest symlink >=20 >=20 > (I'm not so sure if the pkg-static threads for my context > mostly end up waiting for each other, the "gstat -spod" L(q) > generally showing 16..22, sometimes more. biord and getblk > commonly show in top, with at most 1 CPU? showing.) >=20 > The 1hr+ extra makes experimenting more time consuming. I'm > glad it is the faster M4 MAX as the context. It also means > that I'm unlikely to try such on the Windows Dev Kit 2023 > where the time could be much longer. >=20 >=20 > Before reboot (but after bulk -a): >=20 > [00:05:44] [01] [00:00:00] Building www/gitlab@ee | = gitlab-ee-17.10.3 > [00:05:46] [01] [00:00:02] Status www/gitlab@ee | = gitlab-ee-17.10.3: check-sanity > [00:05:46] [01] [00:00:02] Status www/gitlab@ee | = gitlab-ee-17.10.3: pkg-depends > [00:05:46] [01] [00:00:02] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch-depends > [00:05:46] [01] [00:00:02] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch > [00:05:56] [01] [00:00:12] Status www/gitlab@ee | = gitlab-ee-17.10.3: checksum > [00:05:56] [01] [00:00:12] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract-depends > [00:08:25] [01] [00:02:41] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract > [00:08:34] [01] [00:02:50] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch-depends > [00:08:34] [01] [00:02:50] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch > [00:08:34] [01] [00:02:50] Status www/gitlab@ee | = gitlab-ee-17.10.3: build-depends > [00:27:47] [01] [00:22:03] Status www/gitlab@ee | = gitlab-ee-17.10.3: lib-depends > [00:27:47] [01] [00:22:03] Status www/gitlab@ee | = gitlab-ee-17.10.3: configure > [00:27:48] [01] [00:22:04] Status www/gitlab@ee | = gitlab-ee-17.10.3: build > [00:27:48] [01] [00:22:04] Status www/gitlab@ee | = gitlab-ee-17.10.3: run-depends > [00:27:48] [01] [00:22:04] Status www/gitlab@ee | = gitlab-ee-17.10.3: stage > [00:27:53] [01] [00:22:09] Status www/gitlab@ee | = gitlab-ee-17.10.3: package > [00:29:40] [01] [00:23:56] Finished www/gitlab@ee | = gitlab-ee-17.10.3: Success >=20 > So, somewhat over 19 min build-depends -> lib-depends. >=20 > After reboot: >=20 > [00:05:58] [01] [00:00:00] Building www/gitlab@ee | = gitlab-ee-17.10.3 > [00:05:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: check-sanity > [00:05:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: pkg-depends > [00:05:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch-depends > [00:05:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch > [00:06:06] [01] [00:00:08] Status www/gitlab@ee | = gitlab-ee-17.10.3: checksum > [00:06:06] [01] [00:00:08] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract-depends > [00:09:37] [01] [00:03:39] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract > [00:09:46] [01] [00:03:48] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch-depends > [00:09:46] [01] [00:03:48] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch > [00:09:46] [01] [00:03:48] Status www/gitlab@ee | = gitlab-ee-17.10.3: build-depends > [00:26:31] [01] [00:20:33] Status www/gitlab@ee | = gitlab-ee-17.10.3: lib-depends > [00:26:31] [01] [00:20:33] Status www/gitlab@ee | = gitlab-ee-17.10.3: configure > [00:26:31] [01] [00:20:33] Status www/gitlab@ee | = gitlab-ee-17.10.3: build > [00:26:31] [01] [00:20:33] Status www/gitlab@ee | = gitlab-ee-17.10.3: run-depends > [00:26:32] [01] [00:20:34] Status www/gitlab@ee | = gitlab-ee-17.10.3: stage > [00:26:37] [01] [00:20:39] Status www/gitlab@ee | = gitlab-ee-17.10.3: package > [00:28:07] [01] [00:22:09] Finished www/gitlab@ee | = gitlab-ee-17.10.3: Success >=20 > So, somewhat over 16 min build-depends -> lib-depends. >=20 > So, say, around 18 min for both before reboot and after it. = Reproducible > for general timescale. >=20 >=20 > During the earlier "bulk -a" www/gitlab@ee got: >=20 > [1D:19:47:18] [07] [00:00:00] Building www/gitlab@ee | = gitlab-ee-17.10.3 > [1D:19:47:19] [07] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: check-sanity > [1D:19:47:19] [07] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: pkg-depends > [1D:19:47:20] [07] [00:00:02] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch-depends > [1D:19:47:20] [07] [00:00:02] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch > [1D:19:47:25] [07] [00:00:07] Status www/gitlab@ee | = gitlab-ee-17.10.3: checksum > [1D:19:47:25] [07] [00:00:07] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract-depends > [1D:19:48:19] [07] [00:01:01] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract > [1D:19:48:50] [07] [00:01:32] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch-depends > [1D:19:48:50] [07] [00:01:32] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch > [1D:19:48:50] [07] [00:01:32] Status www/gitlab@ee | = gitlab-ee-17.10.3: build-depends > [1D:21:11:47] [07] [01:24:29] Status www/gitlab@ee | = gitlab-ee-17.10.3: lib-depends > [1D:21:11:47] [07] [01:24:29] Status www/gitlab@ee | = gitlab-ee-17.10.3: configure > [1D:21:11:48] [07] [01:24:30] Status www/gitlab@ee | = gitlab-ee-17.10.3: build > [1D:21:11:48] [07] [01:24:30] Status www/gitlab@ee | = gitlab-ee-17.10.3: run-depends > [1D:21:11:50] [07] [01:24:32] Status www/gitlab@ee | = gitlab-ee-17.10.3: stage > [1D:21:11:57] [07] [01:24:39] Status www/gitlab@ee | = gitlab-ee-17.10.3: package > [1D:21:16:11] [07] [01:28:53] Finished www/gitlab@ee | = gitlab-ee-17.10.3: Success >=20 > where the load averages were near the FreeBSD cpu count over > the time frame. >=20 > So, it appears that competing for I/O bandwidth with the > other builders makes the difference of: >=20 > around 18 min vs. around 83 min for build-depends -> lib-depends . I'll note that ampere2's main-arm64has started its 15th day of building (341 hrs+) and still had 6748 packages remaining as of when I wrote this. pkg 2.1.0 based non-parallel builds on M4 MAX with debug kernel: (I did not want to wait for the Windows Dev Kit 2023.) # poudriere bulk -jrelease-aarch64 -J1:15 -v -palt -C www/rt50 = devel/py-inline-snapshot@py311 mail/mailest@nox devel/dwarves = net-mgmt/fastnetmon www/gitlab@ee . . . (Note: presented in the same sequence as above) . . . [00:12:57] [01] [00:00:00] Building www/rt50 | rt50-5.0.7 [00:12:59] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: = check-sanity [00:12:59] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: pkg-depends [00:12:59] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: = fetch-depends [00:12:59] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: fetch [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: checksum [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = extract-depends [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: extract [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = patch-depends [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: patch [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = build-depends [00:19:09] [01] [00:06:12] Status www/rt50 | rt50-5.0.7: lib-depends [00:19:09] [01] [00:06:12] Status www/rt50 | rt50-5.0.7: configure [00:19:10] [01] [00:06:13] Status www/rt50 | rt50-5.0.7: build [00:19:10] [01] [00:06:13] Status www/rt50 | rt50-5.0.7: run-depends [00:19:10] [01] [00:06:13] Status www/rt50 | rt50-5.0.7: stage [00:19:11] [01] [00:06:14] Status www/rt50 | rt50-5.0.7: package [00:19:18] [01] [00:06:21] Finished www/rt50 | rt50-5.0.7: Success . . . [00:11:58] [01] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 [00:11:59] [01] [00:00:01] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends [00:12:22] [01] [00:00:24] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends [00:12:22] [01] [00:00:24] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure [00:12:22] [01] [00:00:24] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build [00:12:22] [01] [00:00:24] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends [00:12:56] [01] [00:00:58] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage [00:12:56] [01] [00:00:58] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package [00:12:57] [01] [00:00:59] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success . . . [00:06:37] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 [00:06:38] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity [00:06:38] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch [00:06:40] [01] [00:00:03] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends [00:06:40] [01] [00:00:03] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends [00:10:16] [01] [00:03:39] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure [00:10:16] [01] [00:03:39] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build [00:10:17] [01] [00:03:40] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends [00:10:31] [01] [00:03:54] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage [00:10:31] [01] [00:03:54] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package [00:10:31] [01] [00:03:54] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success . . . [00:10:34] [01] [00:00:00] Building devel/dwarves | dwarves-1.19_3 [00:10:36] [01] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = check-sanity [00:10:36] [01] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = pkg-depends [00:10:36] [01] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = fetch-depends [00:10:36] [01] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = fetch [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = checksum [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = extract-depends [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = extract [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = patch-depends [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = patch [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = build-depends [00:11:42] [01] [00:01:08] Status devel/dwarves | dwarves-1.19_3: = lib-depends [00:11:53] [01] [00:01:19] Status devel/dwarves | dwarves-1.19_3: = configure [00:11:54] [01] [00:01:20] Status devel/dwarves | dwarves-1.19_3: = build [00:11:54] [01] [00:01:20] Status devel/dwarves | dwarves-1.19_3: = run-depends [00:11:54] [01] [00:01:20] Status devel/dwarves | dwarves-1.19_3: = stage [00:11:54] [01] [00:01:20] Status devel/dwarves | dwarves-1.19_3: = package [00:11:55] [01] [00:01:21] Finished devel/dwarves | dwarves-1.19_3: = Success . . . [00:19:21] [01] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 [00:19:21] [01] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity [00:19:21] [01] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends [00:19:45] [01] [00:00:24] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends [00:20:21] [01] [00:01:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure [00:20:22] [01] [00:01:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build [00:20:34] [01] [00:01:13] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends [00:20:34] [01] [00:01:13] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage [00:20:34] [01] [00:01:13] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package [00:20:35] [01] [00:01:14] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success . . . [00:20:36] [01] [00:00:00] Building www/gitlab@ee | gitlab-ee-17.10.3 [00:20:36] [01] [00:00:00] Status www/gitlab@ee | gitlab-ee-17.10.3: = check-sanity [00:20:36] [01] [00:00:00] Status www/gitlab@ee | gitlab-ee-17.10.3: = pkg-depends [00:20:36] [01] [00:00:00] Status www/gitlab@ee | gitlab-ee-17.10.3: = fetch-depends [00:20:36] [01] [00:00:00] Status www/gitlab@ee | gitlab-ee-17.10.3: = fetch [00:20:42] [01] [00:00:06] Status www/gitlab@ee | gitlab-ee-17.10.3: = checksum [00:20:42] [01] [00:00:06] Status www/gitlab@ee | gitlab-ee-17.10.3: = extract-depends [00:20:54] [01] [00:00:18] Status www/gitlab@ee | gitlab-ee-17.10.3: = extract [00:21:04] [01] [00:00:28] Status www/gitlab@ee | gitlab-ee-17.10.3: = patch-depends [00:21:04] [01] [00:00:28] Status www/gitlab@ee | gitlab-ee-17.10.3: = patch [00:21:04] [01] [00:00:28] Status www/gitlab@ee | gitlab-ee-17.10.3: = build-depends [00:38:07] [01] [00:17:31] Status www/gitlab@ee | gitlab-ee-17.10.3: = lib-depends [00:38:07] [01] [00:17:31] Status www/gitlab@ee | gitlab-ee-17.10.3: = configure [00:38:07] [01] [00:17:31] Status www/gitlab@ee | gitlab-ee-17.10.3: = build [00:38:07] [01] [00:17:31] Status www/gitlab@ee | gitlab-ee-17.10.3: = run-depends [00:38:08] [01] [00:17:32] Status www/gitlab@ee | gitlab-ee-17.10.3: = stage [00:38:14] [01] [00:17:38] Status www/gitlab@ee | gitlab-ee-17.10.3: = package [00:39:51] [01] [00:19:15] Finished www/gitlab@ee | gitlab-ee-17.10.3: = Success FYI: [00:39:52] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [01:44:54] Committing packages to repository: = /usr/local/poudriere/data/packages/release-aarch64-alt/.real_1744702202 = via .latest symlink pkg 2.0.6 based non-parallel builds on M4 MAX with debug kernel: (No general "bulk -a" was done for the pkg 2.0.6 context.) # poudriere bulk -jrelease-aarch64 -J1:15 -v -pdefault -C www/rt50 = devel/py-inline-snapshot@py311 mail/mailest@nox devel/dwarves = net-mgmt/fastnetmon www/gitlab@ee . . . (Note: presented in the same sequence as above) . . . [00:01:26] [01] [00:00:00] Building www/rt50 | rt50-5.0.7 [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: = check-sanity [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: pkg-depends [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: = fetch-depends [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: fetch [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: checksum [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: = extract-depends [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: extract [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: = patch-depends [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: patch [00:01:28] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: = build-depends [00:01:30] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: lib-depends [00:01:30] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: configure [00:01:30] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: build [00:01:30] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: run-depends [00:01:31] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: stage [00:01:31] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: package [00:01:39] [01] [00:00:13] Finished www/rt50 | rt50-5.0.7: Success . . . [00:01:23] [01] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1 [00:01:23] [01] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.18.1 [00:01:24] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: check-sanity [00:01:24] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: pkg-depends [00:01:24] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: fetch-depends [00:01:24] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: fetch [00:01:24] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: checksum [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: extract-depends [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: extract [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: patch-depends [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: patch [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: build-depends [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: lib-depends [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: configure [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: build [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: run-depends [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: stage [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: package [00:01:25] [01] [00:00:02] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: Success . . . [00:01:16] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 [00:01:17] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity [00:01:17] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build [00:01:19] [01] [00:00:03] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends [00:01:20] [01] [00:00:04] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage [00:01:20] [01] [00:00:04] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package [00:01:20] [01] [00:00:04] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success . . . [00:01:11] [01] [00:00:00] Building devel/dwarves | dwarves-1.19_3 [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = check-sanity [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = pkg-depends [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch-depends [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = checksum [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = extract-depends [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = extract [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = patch-depends [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = patch [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = build-depends [00:01:13] [01] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = lib-depends [00:01:14] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = configure [00:01:14] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = build [00:01:14] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = run-depends [00:01:14] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = stage [00:01:15] [01] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = package [00:01:15] [01] [00:00:04] Finished devel/dwarves | dwarves-1.19_3: = Success . . . [00:01:40] [01] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends [00:01:42] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends [00:01:43] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure [00:01:43] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build [00:01:56] [01] [00:00:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends [00:01:56] [01] [00:00:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage [00:01:56] [01] [00:00:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package [00:01:57] [01] [00:00:17] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success . . . [00:01:58] [01] [00:00:00] Building www/gitlab@ee | gitlab-ee-17.9.2_1 [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: check-sanity [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: pkg-depends [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: fetch-depends [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: fetch [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: checksum [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: extract-depends [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: extract [00:02:09] [01] [00:00:11] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: patch-depends [00:02:09] [01] [00:00:11] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: patch [00:02:09] [01] [00:00:11] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: build-depends [00:02:21] [01] [00:00:23] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: lib-depends [00:02:21] [01] [00:00:23] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: configure [00:02:21] [01] [00:00:23] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: build [00:02:21] [01] [00:00:23] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: run-depends [00:02:22] [01] [00:00:24] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: stage [00:02:28] [01] [00:00:30] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: package [00:03:59] [01] [00:02:01] Finished www/gitlab@ee | = gitlab-ee-17.9.2_1: Success FYI: [00:04:00] Creating pkg repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [00:04:03] Committing packages to repository: = /usr/local/poudriere/data/packages/release-aarch64-default/.real_174471186= 3 via .latest symlink =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Apr 15 15:41:26 2025 X-Original-To: freebsd-current@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 4ZcT0l0SRzz5tKxs for ; Tue, 15 Apr 2025 15:41:43 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZcT0k01Fmz3lxx for ; Tue, 15 Apr 2025 15:41:42 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=nHuKldbE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5efe8d9ebdfso10873182a12.3 for ; Tue, 15 Apr 2025 08:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744731699; x=1745336499; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=VAo6WM1frLmIMpunED/sWTFJJG/MHevu0IsCVB0rAwk=; b=nHuKldbEV1YMfBQ9GwJLJ5zEb/mOACGYAJ6kHDYYEvTr8D5F2RM2IuGV7EzWDZaBoK Paa7RoxxucF2pGaHnZpM4mfWPinyy6Ajz15pihC6u8PL6MMbALItZ/JKtGT/kbcHXrOk zGawFTjInFMuy2PxVcnksG3S47IXn1w+DYk6s3qqJ11GaYHQe+Jb1xdq3KN9xrJCp7Xl rN0WX0ylCB0ABJmEfQbYh1VIypaB/L27f8xumJ1++q1bfh8zVAtlnuNdQqGuR/FXA0bX SG5HrT/WTJQla3kQ30DXJZV/jOl8Qe7uXYz5kF84R8iZgeXokbTagU4FgwJZNukzsIS6 LRIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744731699; x=1745336499; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=VAo6WM1frLmIMpunED/sWTFJJG/MHevu0IsCVB0rAwk=; b=TYmBgZWviHpmgXc53oA27lsweiuEMbfnzNHk4Cb40cqLnctC8qekB6UCKTkiwhNELc ve4DQhuFi6CsHb9sSeLz8myktpRHURoR49t5EN6G4hfMj3GJkA+Yilnac5i1jDc+rAw3 ZUyMw3FFEIHOSouhS1IUuPBMkFWf9v3tNRz9XyYZhb2KykNfQHMpTGD0GTmvpQBtpR+3 RV5syXpoZK69bjx9MHwQtz2HXrSUMxZitR1S5ZYKxjwuu3Xpkr2aAoclflZ3dsSrtPrA VPDS7CqrLi91p0iQMPA3LaXRqKsey4EVF3CDCtc1vfksB83RIs8oT4MgBJiOl7QsDS+H EVbA== X-Gm-Message-State: AOJu0YzvcRQOMAyGajTPp5rlV8Kzy8eHlH/EGdFSrg0GFfCAk2YdbCjW 7JG8TsgsyEujY9edYRGxIoiyNZb+Ao0xhKj6QqF3E+w0fmiP96Yadc8+kFR6zktQp0REEnde1Vg lrHrGsr3doNPnC+DizakQ+460TA7XwXQ= X-Gm-Gg: ASbGncuSCy4esN8JTeneM6T8mkbPLOXdWmYcYE0DpP+6Y1+5eyuimmW+G/HxEp24F05 eqxQvGB8il4b1cHbw0FpILTOKWm7iYzOL1xux1bvnTi0JKK56zdDCn23Snikw7GrUArgA7AxoWV sstXBD4DlGfVmdWlmizCv2QO/7uNfsWnChqURVv91tqMQbRcfXD5Y0DA== X-Google-Smtp-Source: AGHT+IErJWojtDkJE/I+E+R4/KpPLU5dlKdnSpIDoqk1M73TQyZwdb2sDM1aKF3N62uhR2RsSRKIwvB9rfQwahs8gNU= X-Received: by 2002:a05:6402:2805:b0:5ed:6535:b6d2 with SMTP id 4fb4d7f45d1cf-5f36f77a50fmr13698660a12.15.1744731699245; Tue, 15 Apr 2025 08:41:39 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 From: Rick Macklem Date: Tue, 15 Apr 2025 08:41:26 -0700 X-Gm-Features: ATxdqUFNU5_hD4WPO4FgplJdmw3B7gJYsV92cB4NghX0qzLiYtjB0KNLqUgkzEw Message-ID: Subject: ZFS named attribute patch for review To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [0.03 / 15.00]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_SPAM_LONG(0.48)[0.477]; NEURAL_HAM_SHORT(-0.44)[-0.436]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; TAGGED_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZcT0k01Fmz3lxx X-Spamd-Bar: / Hi, My ZFS patch to add named attribute support for FreeBSD is in phabricator as D49654. I listed a couple of reviewers, but they have not yet responded (a couple of weeks), so if anyone feels comfortable reviewing this code, please do so. Note that once this review is completed, I will set it up as a pull request on OpenZFS. Thanks for your help with a review, rick From nobody Wed Apr 16 20:53:45 2025 X-Original-To: freebsd-current@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 4ZdCtk4BT8z5tDvy for ; Wed, 16 Apr 2025 20:54:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 4ZdCtk1ZdWz426K for ; Wed, 16 Apr 2025 20:54:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=knvDtqV0; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744836840; bh=CJqOne88jpOje04xn6HVGbpu1FWzSrqHBkMH9qFgVgU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=knvDtqV02JW5/gX+6e1Vd5KRN+/ViU+sY6nUw3j1BmjzIgJll/eezFbaFyBGFNLfRMd0+4yPjSiF05IUbBYvhyuFlysKog6ulXmVDXzGvpnjfPHCzgSaMl4VfmE5drKfFWVm9TtOVWsSgdTZE7maRhdkZEX2GNDyKrplQ4D8OKFG5aDWy1RacsfiqaIx+dvKVcIDiu8S7/3H6hZQ3HJPfnOnPOxDGV5GWfrr0vKU6VkpdTD1wI8taA9X6bWn4T4lcSgXdAyFgb+xv4gXXalsFOtWCnpcv2yepeFhX1LArk98z8nzKdqGQcCI4mz6WHf3E1ocpeq4k9yW1PVFo7Po4Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744836840; bh=FXQaFQmSUsqxx6EQKmsi5I8orjK7PKT8iWPsVGAvWdy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=FSVrs8D1dYFVMYK3w8wsaFgWVxQVn00/vTLVkxvj1Q+hsuzN/TyfoUtWZpoDIUPnN/vV7VKD+3Nekn2E22eWj+oXY7qtpL+6UNSV0bqdtYToTu9O2z60n6KmhLHCE39ik6UepX57p2IvsXUN+ycWVxq/mh7joIXyks3JQ2qcu+dMUQNqCWod5B9hoNPV70meWThEzERVSVwuIYd9ONLvr6hvAoE/8IeAvE9+Bzmxm6WjiktEMeae7+Jmwdi4Iqa8LvSdvPOlImhjaakhSB1S+pT+7BvtKDt+DVUWKT4RK85kpR9yTsrQB7k5l/HZ5BaQY6MslcsJD91Xcehu/Cgi3A== X-YMail-OSG: AXK5hIYVM1l.ZKbR.QSFpQJXLLNLvwYwGtY8Bgbg6njLbX2IkuBId3.JmvgIn0R x.ap6AznyEltW8cWhLyqiybEjNSKU7Wa5IlmlKNI066_hRTdVeezQhqtc27UNjHJSgYJgkymbmkW CbbEdPNmqQyaT_8sHC0Wbrn9WX41ERN05NSiYuK6ddipY9vgihzAMu3WljBFDEDOKmrPEKPSbv3v vPFWWRME9XIlmkwi4t26LcfViWLzIL7TX20DnygGt8FhzGufjAymd1g00R2GkRr80cFgDHrbdaMs _7bVaIuEMzQVAsgl_nrgfyPRtDVdCZTJOhKW6ngS0n_Xfr_uWjqdpXjkTcQUwwWDT5JDli2y_lZp N11L_d.PF.25ZO11PfqwsVT2Co1wDckesROlt80fJfHhpx2vz9UIIBG_BUiaAyhxOUvioLwzqoKM SHaaiG3365Zq5IfxVB_X8dOpN6tenjLO9GCf_VvSuizgPl8XvrXWOLetjRr31NWZRYz7aDqZdpvj KvjwZQ_D7DU_ochTda6iwIPFbu1JxGJl_MAIeKX0CapDT3Vme9D9p.eMrwTuIQF269YfZucIOX4a RmOOEvyd_AZfRGcQ.g6VGK_KeOB4bApahgCb0GTcW.XItpBD9eShdFv.0IBWpjR0TRgZxIkG993b n9wPqFvHjjSaxptBZ.Mci55gQagJpRDmj6vPIOrM5GjwmzzoZGCjDdLkciT4GGnH6xVN2dLq2N9e rLernUzAxLcM_THBrFMoIhto1mR5ECpiDe5FMneX2n3EBk.UYYVYqdR8gH7ieDXTM7LPSVcvMVvf gcyTUdn03Nb2hn2oy2KzXh..lLJ86BEfeh4WFxOol9bosOYRwWBGV4mQaWhU3yxpa_MWaJVqGn7O qdVcbsCICUhn.5skeMWOGwmG3_uiZfY0wH7X7EZdgP9QubTkETHTpSbATtDFYN7eQ8kztCfj4bLf bF_JFL5ojZ_O8YST2UH8mOF3H94XjDCXKPF6xShliSNvgfASWbZ7ldixA8fKzgYfJU1NozOf5apn 1K0Z17jMWCM.PN7s5TgOeqyvNPysvae.UkyXdxAmh8IIV6lVCqWInmE6khyF3_mSfSKSL3XQrVc2 mtMUSCNPHIGNiGmPbek9K.Om3jDF7RxDsKCN.7o18GlotIgL9mbNR9crX4cc53bXIBMlnZ7U7b5K SVtuOYRVkm5TiEFfGdXrBM0.FczX0LnRTQadjsd54Ahuwys9p2bFVxvdvFcK7ETVhUvIyIofTifk pqH0Ag5I4A5uk8QKQ3o17EWx.t9crxhovrqGtoGrX5DzFGxntRZEDCqt2E1Ue4IQemGlvlpUa52X 7xFKw697Y.JrrerMMZuOG4ja3MPj6qYpQ7pUAqK84fnPfojEV03Gq891lXpd71FHYl_Z0Py116rt qH0xTHSxKH9vDFCSIGaooT4L9kRMVJzzguh4tdnDNgZ4qNVt.lhk5qO4QrGa5bOORdMUVNtalOK6 ZfOrdKnggL3Rjfz39z5JM5.VsJWAkElAUUP4JBE.VsjyLv3IrTssdXIoacj__BwUQyFWiKF80If2 ArDazHtoX9TARsp.jvZ7j_5VMav9mEydhjB0o2VAXtWcTUbKtQQ2JD4ct0OoGdcrmOkI3VU15GS0 CunDG2wcLYpZtt66yNv6hfzOwnfi975VlQPZXxsBpkDsWpgDin2sebIZgM53esvrXTrOTZ4L1qb8 duR4MFsFZN6bkaazT.Ih2rf8d9ZnWALdRlTSn5S81Kp8nERJ5zi49r8znXfxYj0WiKoz8A_nejN0 13OLQIsbPyCA.J9nb1nqT8gREg48mCzNt9ju06Tlcl7XXAV1GjEwHkOTAivkAKeaFW9_jmk2bpkE zJjo9tGadsPFZjFbq6xG0CQbPIUm3yZIkmjKzmu_B.rTgtl7IGy1WtSdJOJ_WU5tCGLz8Rwl5x4s jZE6kD5XDR7LTY44CdYZ5o9zyuZHUu7pB5KgAS1SUdukRXSdeWq1voszR1eaBss8Mkvvlx4rcjWf EIvBgb_OhAZJmcDN10VN3LlTEYQx3DlPYhdsHZIBIUWxxwgm_GUJ75lPg3MpnTbZooLok76GZyPG UR3muEPTXP4s_ez7R93p72pYxnWAUS4Q5ANh6v6kPENUHGeepsEzFrCjCAWW_vKQ4k40OMhMrwwc mcPwak24Dtc9fg9NAZUBHnPdZ_mY_XVSnrgt0lpU8qN5p9pRWpW5q46xwAXisogjxgexBGtK_HL4 f0sM6tYq0r.e5ykTTYcscQZfOYx.elG1EsYuenQ1gXxndB.55w_l81ERupaCDBgkr4r9WrhRqYc6 uUflWNg-- X-Sonic-MF: X-Sonic-ID: 2c288c2d-4c00-410d-97cb-6c7f86b0c45b Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 16 Apr 2025 20:54:00 +0000 Received: by hermes--production-gq1-74d64bb7d7-6nlps (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 858b6cfe695c27a074c202479d9f586b; Wed, 16 Apr 2025 20:53:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [reproducible examples notes] From: Mark Millard In-Reply-To: Date: Wed, 16 Apr 2025 13:53:45 -0700 Cc: Gleb Popov <6yearold@gmail.com>, FreeBSD Current , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <7E2865C6-BEEA-4059-B24F-8A5F64D9A75C@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> <7ziazrj7szuqhov3oppjbh3jyu3f2p2owntv4oxprelrdjzc6u@hkuf5szf3zwy> <8B070D1D-0524-4DA4-A5C2-EF2CF98C5E15@yahoo.com> <7A1322FA-A118-4F87-9D96-DE8B05E09424@yahoo.com> <6C67E39F-3634-4AF6-95EC-46159E7391E5@yahoo.com> <8308705D-5155-48B2-ADFC-2BCF32F7D55C@yahoo.com> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-2.48 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.147:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.96)[0.957]; NEURAL_HAM_MEDIUM(-0.94)[-0.936]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from] X-Rspamd-Queue-Id: 4ZdCtk1ZdWz426K X-Spamd-Bar: -- [The following ignores www/gitlab@ee because one of its prerequisites ran into a different problem that I've separately reported. The below shows things looking more like normal for the build-depends , lib-depends , and run-depends time frames when using the ports-mgmt/pkg-devel that has the change for avoiding the extra time.] On Apr 15, 2025, at 03:17, Mark Millard wrote: > On Apr 14, 2025, at 16:43, Mark Millard wrote: >=20 >> On Apr 11, 2025, at 23:55, Mark Millard wrote: >>=20 >>> On Apr 11, 2025, at 19:28, Mark Millard wrote: >>>>=20 >>>>> . . . >>>>>=20 >>>> . . . >>>>=20 >>>=20 >>> . . . >>>=20 >>>> . . . > . . . >=20 > I'll note that ampere2's main-arm64has started its 15th day > of building (341 hrs+) and still had 6748 packages remaining > as of when I wrote this. >=20 > pkg 2.1.0 based non-parallel builds on M4 MAX with debug kernel: > (I did not want to wait for the Windows Dev Kit 2023.) >=20 > # poudriere bulk -jrelease-aarch64 -J1:15 -v -palt -C www/rt50 = devel/py-inline-snapshot@py311 mail/mailest@nox devel/dwarves = net-mgmt/fastnetmon www/gitlab@ee > . . . (Note: presented in the same sequence as above) . . . > [00:12:57] [01] [00:00:00] Building www/rt50 | rt50-5.0.7 > [00:12:59] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: = check-sanity > [00:12:59] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: = pkg-depends > [00:12:59] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: = fetch-depends > [00:12:59] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: fetch > [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: checksum > [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = extract-depends > [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: extract > [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = patch-depends > [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: patch > [00:13:00] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = build-depends > [00:19:09] [01] [00:06:12] Status www/rt50 | rt50-5.0.7: = lib-depends > [00:19:09] [01] [00:06:12] Status www/rt50 | rt50-5.0.7: configure > [00:19:10] [01] [00:06:13] Status www/rt50 | rt50-5.0.7: build > [00:19:10] [01] [00:06:13] Status www/rt50 | rt50-5.0.7: = run-depends > [00:19:10] [01] [00:06:13] Status www/rt50 | rt50-5.0.7: stage > [00:19:11] [01] [00:06:14] Status www/rt50 | rt50-5.0.7: package > [00:19:18] [01] [00:06:21] Finished www/rt50 | rt50-5.0.7: Success > . . . > [00:11:58] [01] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8 > [00:11:59] [01] [00:00:01] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.20.8 > [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: check-sanity > [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: pkg-depends > [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch-depends > [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: fetch > [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: checksum > [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract-depends > [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: extract > [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch-depends > [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: patch > [00:11:59] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build-depends > [00:12:22] [01] [00:00:24] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: lib-depends > [00:12:22] [01] [00:00:24] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: configure > [00:12:22] [01] [00:00:24] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: build > [00:12:22] [01] [00:00:24] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: run-depends > [00:12:56] [01] [00:00:58] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: stage > [00:12:56] [01] [00:00:58] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: package > [00:12:57] [01] [00:00:59] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.20.8: Success > . . . > [00:06:37] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 > [00:06:38] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity > [00:06:38] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends > [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends > [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch > [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum > [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends > [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract > [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends > [00:06:39] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch > [00:06:40] [01] [00:00:03] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends > [00:06:40] [01] [00:00:03] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends > [00:10:16] [01] [00:03:39] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure > [00:10:16] [01] [00:03:39] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build > [00:10:17] [01] [00:03:40] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends > [00:10:31] [01] [00:03:54] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage > [00:10:31] [01] [00:03:54] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package > [00:10:31] [01] [00:03:54] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success > . . . > [00:10:34] [01] [00:00:00] Building devel/dwarves | dwarves-1.19_3 > [00:10:36] [01] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = check-sanity > [00:10:36] [01] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = pkg-depends > [00:10:36] [01] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = fetch-depends > [00:10:36] [01] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = fetch > [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = checksum > [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = extract-depends > [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = extract > [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = patch > [00:10:37] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = build-depends > [00:11:42] [01] [00:01:08] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [00:11:53] [01] [00:01:19] Status devel/dwarves | dwarves-1.19_3: = configure > [00:11:54] [01] [00:01:20] Status devel/dwarves | dwarves-1.19_3: = build > [00:11:54] [01] [00:01:20] Status devel/dwarves | dwarves-1.19_3: = run-depends > [00:11:54] [01] [00:01:20] Status devel/dwarves | dwarves-1.19_3: = stage > [00:11:54] [01] [00:01:20] Status devel/dwarves | dwarves-1.19_3: = package > [00:11:55] [01] [00:01:21] Finished devel/dwarves | dwarves-1.19_3: = Success > . . . > [00:19:21] [01] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 > [00:19:21] [01] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity > [00:19:21] [01] [00:00:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends > [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends > [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch > [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum > [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends > [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract > [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends > [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch > [00:19:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends > [00:19:45] [01] [00:00:24] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends > [00:20:21] [01] [00:01:00] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure > [00:20:22] [01] [00:01:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build > [00:20:34] [01] [00:01:13] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends > [00:20:34] [01] [00:01:13] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage > [00:20:34] [01] [00:01:13] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package > [00:20:35] [01] [00:01:14] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success > . . . > [00:20:36] [01] [00:00:00] Building www/gitlab@ee | = gitlab-ee-17.10.3 > [00:20:36] [01] [00:00:00] Status www/gitlab@ee | = gitlab-ee-17.10.3: check-sanity > [00:20:36] [01] [00:00:00] Status www/gitlab@ee | = gitlab-ee-17.10.3: pkg-depends > [00:20:36] [01] [00:00:00] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch-depends > [00:20:36] [01] [00:00:00] Status www/gitlab@ee | = gitlab-ee-17.10.3: fetch > [00:20:42] [01] [00:00:06] Status www/gitlab@ee | = gitlab-ee-17.10.3: checksum > [00:20:42] [01] [00:00:06] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract-depends > [00:20:54] [01] [00:00:18] Status www/gitlab@ee | = gitlab-ee-17.10.3: extract > [00:21:04] [01] [00:00:28] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch-depends > [00:21:04] [01] [00:00:28] Status www/gitlab@ee | = gitlab-ee-17.10.3: patch > [00:21:04] [01] [00:00:28] Status www/gitlab@ee | = gitlab-ee-17.10.3: build-depends > [00:38:07] [01] [00:17:31] Status www/gitlab@ee | = gitlab-ee-17.10.3: lib-depends > [00:38:07] [01] [00:17:31] Status www/gitlab@ee | = gitlab-ee-17.10.3: configure > [00:38:07] [01] [00:17:31] Status www/gitlab@ee | = gitlab-ee-17.10.3: build > [00:38:07] [01] [00:17:31] Status www/gitlab@ee | = gitlab-ee-17.10.3: run-depends > [00:38:08] [01] [00:17:32] Status www/gitlab@ee | = gitlab-ee-17.10.3: stage > [00:38:14] [01] [00:17:38] Status www/gitlab@ee | = gitlab-ee-17.10.3: package > [00:39:51] [01] [00:19:15] Finished www/gitlab@ee | = gitlab-ee-17.10.3: Success >=20 > FYI: >=20 > [00:39:52] Creating pkg repository > Creating repository in /tmp/packages: 100% > Packing files for repository: 100% > [01:44:54] Committing packages to repository: = /usr/local/poudriere/data/packages/release-aarch64-alt/.real_1744702202 = via .latest symlink >=20 >=20 > pkg 2.0.6 based non-parallel builds on M4 MAX with debug kernel: > (No general "bulk -a" was done for the pkg 2.0.6 context.) >=20 > # poudriere bulk -jrelease-aarch64 -J1:15 -v -pdefault -C www/rt50 = devel/py-inline-snapshot@py311 mail/mailest@nox devel/dwarves = net-mgmt/fastnetmon www/gitlab@ee > . . . (Note: presented in the same sequence as above) . . . > [00:01:26] [01] [00:00:00] Building www/rt50 | rt50-5.0.7 > [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: = check-sanity > [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: = pkg-depends > [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: = fetch-depends > [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: fetch > [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: checksum > [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: = extract-depends > [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: extract > [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: = patch-depends > [00:01:27] [01] [00:00:01] Status www/rt50 | rt50-5.0.7: patch > [00:01:28] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: = build-depends > [00:01:30] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = lib-depends > [00:01:30] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: configure > [00:01:30] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: build > [00:01:30] [01] [00:00:04] Status www/rt50 | rt50-5.0.7: = run-depends > [00:01:31] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: stage > [00:01:31] [01] [00:00:05] Status www/rt50 | rt50-5.0.7: package > [00:01:39] [01] [00:00:13] Finished www/rt50 | rt50-5.0.7: Success > . . . > [00:01:23] [01] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1 > [00:01:23] [01] [00:00:00] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.18.1 > [00:01:24] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: check-sanity > [00:01:24] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: pkg-depends > [00:01:24] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: fetch-depends > [00:01:24] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: fetch > [00:01:24] [01] [00:00:01] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: checksum > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: extract-depends > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: extract > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: patch-depends > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: patch > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: build-depends > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: lib-depends > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: configure > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: build > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: run-depends > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: stage > [00:01:25] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: package > [00:01:25] [01] [00:00:02] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: Success > . . . > [00:01:16] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 > [00:01:17] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity > [00:01:17] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure > [00:01:18] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build > [00:01:19] [01] [00:00:03] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends > [00:01:20] [01] [00:00:04] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage > [00:01:20] [01] [00:00:04] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package > [00:01:20] [01] [00:00:04] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success > . . . > [00:01:11] [01] [00:00:00] Building devel/dwarves | dwarves-1.19_3 > [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = check-sanity > [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = pkg-depends > [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch-depends > [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = fetch > [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = checksum > [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = extract-depends > [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = extract > [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = patch-depends > [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = patch > [00:01:12] [01] [00:00:01] Status devel/dwarves | dwarves-1.19_3: = build-depends > [00:01:13] [01] [00:00:02] Status devel/dwarves | dwarves-1.19_3: = lib-depends > [00:01:14] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = configure > [00:01:14] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = build > [00:01:14] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = run-depends > [00:01:14] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = stage > [00:01:15] [01] [00:00:04] Status devel/dwarves | dwarves-1.19_3: = package > [00:01:15] [01] [00:00:04] Finished devel/dwarves | dwarves-1.19_3: = Success > . . . > [00:01:40] [01] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 > [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity > [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends > [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends > [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch > [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum > [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends > [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract > [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends > [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch > [00:01:41] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends > [00:01:42] [01] [00:00:02] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends > [00:01:43] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure > [00:01:43] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build > [00:01:56] [01] [00:00:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends > [00:01:56] [01] [00:00:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage > [00:01:56] [01] [00:00:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package > [00:01:57] [01] [00:00:17] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success > . . . > [00:01:58] [01] [00:00:00] Building www/gitlab@ee | = gitlab-ee-17.9.2_1 > [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: check-sanity > [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: pkg-depends > [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: fetch-depends > [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: fetch > [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: checksum > [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: extract-depends > [00:01:59] [01] [00:00:01] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: extract > [00:02:09] [01] [00:00:11] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: patch-depends > [00:02:09] [01] [00:00:11] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: patch > [00:02:09] [01] [00:00:11] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: build-depends > [00:02:21] [01] [00:00:23] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: lib-depends > [00:02:21] [01] [00:00:23] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: configure > [00:02:21] [01] [00:00:23] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: build > [00:02:21] [01] [00:00:23] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: run-depends > [00:02:22] [01] [00:00:24] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: stage > [00:02:28] [01] [00:00:30] Status www/gitlab@ee | = gitlab-ee-17.9.2_1: package > [00:03:59] [01] [00:02:01] Finished www/gitlab@ee | = gitlab-ee-17.9.2_1: Success >=20 > FYI: >=20 > [00:04:00] Creating pkg repository > Creating repository in /tmp/packages: 100% > Packing files for repository: 100% > [00:04:03] Committing packages to repository: = /usr/local/poudriere/data/packages/release-aarch64-default/.real_174471186= 3 via .latest symlink I updated the alternate environment to be based on using the updates ports-mgmt/pkg-devel that has the time-reduction update. The below is again for the debug PkgBase kernel and the M4 MAX. It shows more like back to normal, unlike the above pkg 2.1.0 runs. [00:02:05] [01] [00:00:00] Building www/rt50 | rt50-5.0.7 [00:02:07] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: = check-sanity [00:02:07] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: pkg-depends [00:02:07] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: = fetch-depends [00:02:07] [01] [00:00:02] Status www/rt50 | rt50-5.0.7: fetch [00:02:08] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: checksum [00:02:08] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = extract-depends [00:02:08] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: extract [00:02:08] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = patch-depends [00:02:08] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: patch [00:02:08] [01] [00:00:03] Status www/rt50 | rt50-5.0.7: = build-depends [00:02:12] [01] [00:00:07] Status www/rt50 | rt50-5.0.7: lib-depends [00:02:12] [01] [00:00:07] Status www/rt50 | rt50-5.0.7: configure [00:02:13] [01] [00:00:08] Status www/rt50 | rt50-5.0.7: build [00:02:13] [01] [00:00:08] Status www/rt50 | rt50-5.0.7: run-depends [00:02:13] [01] [00:00:08] Status www/rt50 | rt50-5.0.7: stage [00:02:14] [01] [00:00:09] Status www/rt50 | rt50-5.0.7: package [00:02:21] [01] [00:00:16] Finished www/rt50 | rt50-5.0.7: Success . . . [00:02:02] [01] [00:00:00] Building devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1 [00:02:03] [01] [00:00:01] Allowing MAKE_JOBS for = devel/py-inline-snapshot@py311 | py311-inline-snapshot-0.18.1 [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: check-sanity [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: pkg-depends [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: fetch-depends [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: fetch [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: checksum [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: extract-depends [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: extract [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: patch-depends [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: patch [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: build-depends [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: lib-depends [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: configure [00:02:04] [01] [00:00:02] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: build [00:02:05] [01] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: run-depends [00:02:05] [01] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: stage [00:02:05] [01] [00:00:03] Status devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: package [00:02:05] [01] [00:00:03] Finished devel/py-inline-snapshot@py311 | = py311-inline-snapshot-0.18.1: Success . . . [00:01:52] [01] [00:00:00] Building mail/mailest@nox | = mailest-emacs_nox-0.9.24_21 [00:01:53] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: check-sanity [00:01:53] [01] [00:00:01] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: pkg-depends [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch-depends [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: fetch [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: checksum [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract-depends [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: extract [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch-depends [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: patch [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build-depends [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: lib-depends [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: configure [00:01:54] [01] [00:00:02] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: build [00:01:55] [01] [00:00:03] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: run-depends [00:02:01] [01] [00:00:09] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: stage [00:02:01] [01] [00:00:09] Status mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: package [00:02:01] [01] [00:00:09] Finished mail/mailest@nox | = mailest-emacs_nox-0.9.24_21: Success . . . [00:01:39] [01] [00:00:00] Building devel/dwarves | dwarves-1.19_3 [00:01:42] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = check-sanity [00:01:42] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = pkg-depends [00:01:42] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = fetch-depends [00:01:42] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = fetch [00:01:42] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = checksum [00:01:42] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = extract-depends [00:01:42] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = extract [00:01:42] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = patch-depends [00:01:42] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = patch [00:01:42] [01] [00:00:03] Status devel/dwarves | dwarves-1.19_3: = build-depends [00:01:50] [01] [00:00:11] Status devel/dwarves | dwarves-1.19_3: = lib-depends [00:01:51] [01] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = configure [00:01:51] [01] [00:00:12] Status devel/dwarves | dwarves-1.19_3: = build [00:01:52] [01] [00:00:13] Status devel/dwarves | dwarves-1.19_3: = run-depends [00:01:52] [01] [00:00:13] Status devel/dwarves | dwarves-1.19_3: = stage [00:01:52] [01] [00:00:13] Status devel/dwarves | dwarves-1.19_3: = package [00:01:52] [01] [00:00:13] Finished devel/dwarves | dwarves-1.19_3: = Success . . . [00:02:21] [01] [00:00:00] Building net-mgmt/fastnetmon | = fastnetmon-1.2.8 [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: check-sanity [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: pkg-depends [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch-depends [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: fetch [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: checksum [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract-depends [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: extract [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch-depends [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: patch [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build-depends [00:02:22] [01] [00:00:01] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: lib-depends [00:02:24] [01] [00:00:03] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: configure [00:02:25] [01] [00:00:04] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: build [00:02:37] [01] [00:00:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: run-depends [00:02:37] [01] [00:00:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: stage [00:02:37] [01] [00:00:16] Status net-mgmt/fastnetmon | = fastnetmon-1.2.8: package [00:02:38] [01] [00:00:17] Finished net-mgmt/fastnetmon | = fastnetmon-1.2.8: Success . . . (No www/gitlab@ee this time.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 16 21:14:24 2025 X-Original-To: current@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 4ZdDLC6Nr9z5tFC2 for ; Wed, 16 Apr 2025 21:14:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZdDLC5kzPz44Jn for ; Wed, 16 Apr 2025 21:14:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744838067; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=AklVVolBGn6oWNsEA8BAIGLahlhagmxHxAAB84axlq8=; b=rb9Kx6aEq57psysw99hxWWlV5zZGLQK3LUwD7AWMhe9B24MYr3ouAEwft7JeMkxQABOymG 58UOzp1s5deR3e/vt79eDHbTTjLwzXi/Kud94JKsBzOeRCWbLxWqak2glwbc9CTcLjw2Mu SrdQsnijsTUK6vzDx9PwM3Zf4yQRTtL3/H1oqape1CrVtN17bo0nolVq88Obgc2BfHusqo 16Ius/rN+ci1Q8hvo4y1x9ZA67z+X6OP5zaIi2TYVNuAZJ8lnxBywNsL0/vBVnXItYY1DK eu0rDu6cRykoROaxocvU6ONG38Vi8F9+ZfUjwVowEJG/D1rLsMvxDmoUiZpDyw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744838067; a=rsa-sha256; cv=none; b=yljaNco4QJ0m1L+hlw1JrPzbXgtb0NFJmYyVTHQtNzV5EiBoqCi5QlhyKMcb7/LNgvSjMe cj+kgGahj2S4bMNATVTu2L1cFxUlgwURuKf9orzsZ83+/qMo9SiAZdO6Q2vyh0n2fPqHwe 7aaDklbfRD4Ty1sasnViMjBg24gOSimbkXHZMPjrcxah/GAX0UGmaMUPczO7NOHNqBmeEv 3Przx+4JYM4TCCw8XZkolsvvHKC1DGMsJdaVdxRIMwWdffZ6F3vBjOybhIcBp/1Fud4fwl ar2CtFlIrqhQFt6H1lg/SiUXWlNLKY2kdyfCbq7/ZdxbWKkrt+qVAlkHl+Vn1g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744838067; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=AklVVolBGn6oWNsEA8BAIGLahlhagmxHxAAB84axlq8=; b=hpR9zIUMCBLd6jKKFzQdFrzYzbglNKkIPT8NdMoo7HDP8Ss/gr9/PvDdIduW2RVSHBxN4+ vejQS2GcWFw3YavL5alFQ5zbof4KK1Oi/a/EFrcYshLsCr+TyLPFwx9aiFHzZpiB+7ZNOh HS9pRJMIeqLgGHvGkI0DtGIdHg9PsO16M+3EYYGSgZ/pShqzmbSyqB5VdLDlPYJFjqVoVs syi5zKGKLepuQ367u0qGr70yEaMbWje1cv5nHp0/2cOAvCiKQzZTwf/ce2UQx2JEa2XUEY 0ln7RsT/on563HgP2DYUe4ZBzAchbvBGO43Bmtouf7jvr50pZdzi8uF0+ebX9A== Received: from [192.168.0.88] (unknown [93.188.39.137]) (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) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZdDLC36b5z15Zp for ; Wed, 16 Apr 2025 21:14:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <16457a38-c381-4234-b4fe-4e0d5afe73ea@FreeBSD.org> Date: Thu, 17 Apr 2025 00:14:24 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: WITHOUT_CLANG + WITH_CLANG_BOOTSTRAP seems to be broken From: Andriy Gapon To: FreeBSD Current References: <058958c0-9024-4444-846c-7255cd367ea2@FreeBSD.org> Content-Language: en-US Autocrypt: addr=avg@FreeBSD.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 In-Reply-To: <058958c0-9024-4444-846c-7255cd367ea2@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I am going to open a PR for this, but I wonder if no one else is seeing this or if no one else cares. I'd imagine that a build configuration like mine is not so exotic. E.g., likes of nanobsd could be using something like it. For me, reproducing the issue is very trivial. E.g., I do this on a recently upgraded host built from main, in a source tree for releng/14.2 branch: $ env MAKEOBJDIRPREFIX=/usr/obj/test make -s -j12 toolchain __MAKE_CONF=/dev/null SRCCONF=/dev/null WITHOUT_CLANG=t make[1]: "/usr/home/avg/devel/freebsd-src-new/upstream/releng/14.2/Makefile.inc1" line 339: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. make[1]: "/usr/home/avg/devel/freebsd-src-new/upstream/releng/14.2/Makefile.inc1" line 344: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. -------------------------------------------------------------- >>> Cleaning up the temporary build tree -------------------------------------------------------------- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- Linking host tools into /usr/obj/test/usr/home/avg/devel/freebsd-src-new/upstream/releng/14.2/amd64.amd64/tmp/legacy/bin -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- ===> tools/build (obj,includes,all,install) 0.12 real 0.05 user 0.09 sys -------------------------------------------------------------- >>> stage 1.2: bootstrap tools -------------------------------------------------------------- ... -------------------------------------------------------------- >>> stage 2.1: cleaning up the object tree -------------------------------------------------------------- ... -------------------------------------------------------------- >>> stage 2.3: build tools -------------------------------------------------------------- ... -------------------------------------------------------------- >>> stage 3: cross tools -------------------------------------------------------------- ===> lib/clang (obj,all,install) ===> lib/clang/libllvm (all) ===> lib/clang/libllvm (install) ===> usr.bin/clang (obj,all,install) ===> usr.bin/clang/lld (obj,all,install) ===> lib/libelftc (obj,all,install) ===> lib/libpe (obj,all,install) ===> usr.bin/elfctl (obj,all,install) ===> usr.bin/elfdump (obj,all,install) ===> usr.bin/objcopy (obj,all,install) ===> usr.bin/nm (obj,all,install) ===> usr.bin/size (obj,all,install) ===> usr.bin/strings (obj,all,install) ===> usr.bin/addr2line (obj,all,install) ===> cddl/lib/libctf (obj,all,install) ===> cddl/lib/libspl (obj,all,install) ===> cddl/usr.bin/ctfconvert (obj,all,install) ===> cddl/usr.bin/ctfmerge (obj,all,install) ===> stand/usb/tools (obj,all,install) 634.09 real 6925.37 user 229.17 sys 0.04 real 0.00 user 0.04 sys As you can see, usr.bin/clang/clan is missing from the output. Also: $ ls -l /usr/obj/test/.../releng/14.2/amd64.amd64/tmp/bin total 0 $ ls -l /usr/obj/test/.../releng/14.2/amd64.amd64/tmp/usr/bin total 40247 -rwxr-xr-x 1 avg wheel 2116760 16 Apr 23:48 addr2line -rwxr-xr-x 1 avg wheel 2595200 16 Apr 23:48 ctfconvert -rwxr-xr-x 1 avg wheel 1997104 16 Apr 23:48 ctfmerge -rwxr-xr-x 1 avg wheel 1411856 16 Apr 23:48 elfctl -rwxr-xr-x 1 avg wheel 1238064 16 Apr 23:48 elfdump lrwxr-xr-x 1 avg wheel 6 16 Apr 23:48 ld -> ld.lld -rwxr-xr-x 1 avg wheel 51724952 16 Apr 23:48 ld.lld -rwxr-xr-x 1 avg wheel 2132480 16 Apr 23:48 nm -rwxr-xr-x 1 avg wheel 2337048 16 Apr 23:48 objcopy -rwxr-xr-x 1 avg wheel 1479664 16 Apr 23:48 size -rwxr-xr-x 1 avg wheel 1425008 16 Apr 23:48 strings lrwxr-xr-x 1 avg wheel 101 16 Apr 23:48 strip -> /usr/obj/test/.../releng/14.2/amd64.amd64/tmp/usr/bin/objcopy -rwxr-xr-x 1 avg wheel 1220848 16 Apr 23:48 sysinit As you can see, clang binaries are not in the expected place. Furthermore, the build just fails down the line. On 11/04/2025 12:29, Andriy Gapon wrote: > > I think that WITHOUT_CLANG + WITH_CLANG_BOOTSTRAP (the latter is the default and > doesn't need to be explicit) is supposed to work. > > I think that the combination should result in building clang as a cross-tool for > the rest of the build, but not building clang for the target. > > However, it seems that the combination is broken at the moment in that the > cross-tool clang is not getting built and the host clang gets used for the build. > > I have recently discovered this issue while trying to build releng/14.2 on a > main (aka 15-CURRENT) host with WITHOUT_CLANG in src.conf.  Host and target > architectures are the same, amd64. > 14.2 has clang 18 as a compiler, while main has clang 19. > The same problem exists for WITHOUT_TOOLCHAIN as well. > > I think that this used to work. Or maybe I was just lucky and the compilers were > either the same or sufficiently compatible that the host compiler could compile > the branch code. > > I think that >     .if ${MK_CLANG} != "no" >     SUBDIR+=        clang >     .endif > in usr.bin/clang/Makefile is the reason why the cross-tool clang is not built > when WITHOUT_CLANG is set. > > A bit more of info is in the forwarded message and the thread to which it belongs. > > What's curious is that those lines are there since commit 8e1c989abbd1db4 "Don't > build and install {llvm,clang,lldb}-tblgen for the target", but I only noticed > the problem a few days ago.  And apparenlty nobody else has seen it. > I'd imagine that the reported configuration is not too exotic. > So, not sure what and when get broken. > It could also be something with my build environment... > > -------- Forwarded Message -------- > Subject: Re: c++ error when trying to build releng/14.2 on 'main' host > Date: Thu, 10 Apr 2025 09:05:47 +0300 > From: Andriy Gapon > To: Dimitry Andric > CC: toolchain@freebsd.org > > On 09/04/2025 8:28 pm, Andriy Gapon wrote: >> What's interesting is that I saw this during the build (make with -s option): >> -------------------------------------------------------------- >>  >>> stage 3: cross tools >> -------------------------------------------------------------- >> ===> lib/clang (obj,all,install) >> ===> lib/clang/libllvm (all) >> ===> lib/clang/libllvm (install) >> ===> usr.bin/clang (obj,all,install) >> ===> usr.bin/clang/lld (obj,all,install) > > When I compared this to other builds, I noticed a missing bit: > ===> usr.bin/clang/clang (all) > ===> usr.bin/clang/clang (install) > > usr.bin/clang/Makefile has this near the top: > .if ${MK_CLANG} != "no" > SUBDIR+=        clang > .endif > > If I read this right, it means that the actual clang is not built/installed if > WITHOUT_CLANG is configured. > Even in the cross-tools stage! > > I am not sure how it worked before as I do not see any recent changes in that > direct area.  Not sure when and what went wrong.  Maybe it's something in one > of .mk include files, maybe something in my environment. > > As hack I tried this change and it seems to have helped: > --- a/Makefile.inc1 > +++ b/Makefile.inc1 > @@ -787,6 +787,7 @@ >  # TOOLS_PREFIX set in BMAKE >  XMAKE=         ${BMAKE} \ >                 TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \ > +               MK_CLANG=${MK_CLANG_BOOTSTRAP} \ >                 MK_LLDB=no \ >                 MK_LLVM_BINUTILS=no \ >                 MK_TESTS=no > > I hope that more knowledgeable people can see what the problem could be, > wherever it is. > >> ===> lib/libelftc (obj,all,install) >> ===> lib/libpe (obj,all,install) >> ===> usr.bin/elfctl (obj,all,install) >> ===> usr.bin/elfdump (obj,all,install) >> ===> usr.bin/objcopy (obj,all,install) >> ===> usr.bin/nm (obj,all,install) >> ===> usr.bin/size (obj,all,install) >> ===> usr.bin/strings (obj,all,install) >> ===> usr.bin/addr2line (obj,all,install) >> ===> cddl/lib/libctf (obj,all,install) >> ===> cddl/lib/libspl (obj,all,install) >> ===> cddl/usr.bin/ctfconvert (obj,all,install) >> ===> cddl/usr.bin/ctfmerge (obj,all,install) >> ===> stand/usb/tools (obj,all,install) > > -- Andriy Gapon From nobody Wed Apr 16 21:17:41 2025 X-Original-To: freebsd-current@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 4ZdDQD1pJFz5tGCG for ; Wed, 16 Apr 2025 21:17:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 4ZdDQC3Dt9z460d for ; Wed, 16 Apr 2025 21:17:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=I74i8WfG; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744838273; bh=eUV+B/DMHl8rRSfmAS+IeJut1cp5lyi6q7XTM4K9iEw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=I74i8WfGXNVhiDx0oLHSaQnNGJ/nujbWTOigqthP6SZ+h9j8V4x2Qd9YXbnjcjxvwZNKJdFX1I0pjOxS+qGsgb65jGJ7i0SdJhLjxDWxosLpGnuRNS7O9tIHr+C2PTKO/fxEy8fJ0FvwI9+WW/40Wk+KrW2wMDvyUlUQvsPw8DbjrybChQN6VonTbdZyrnCYqou9Ck2AALKWlevG0G23P7P/p6egpAG5LKdnr173idHeNgdT/Bk4usBh8AqUmndxg07br/wnt4TvDbL1+sS8DkFdM+lSxOOW3i1/0tS4dSARmK72lQNfrdnlWCXmdsrOkkfGftp+dsOdCdSpToUtYg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744838273; bh=yuxq4bU7r9DhyueSDSXeUVoTshpSYeQJ+6ovLIwwJ5u=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=pBOgB2lhjDnrz5Emupf2NCHV9qtEH5XvtJCVUQdErShGnbiVjkZqzknku7GrJniqJKJFe0TYuipGAFAKyRXTDA5zvLkwl/zSmM/xmECXGsH2b1OYHABu0eBZ9QDBMOU5gUvjdfn0IqW95xscPb/JQ1zyQkY49AnazeW8GQAQ/v60BOhWaP22K/hrLWJ1PVC8LIvkYKDOuH3bSKh7fv1ee9gHm9fYloxipqlwxftJBzPnM24YdnrRRoZ9425pNn8N90OxL07zM0keDM4qS3vHNeso6pKuN4d+nQ1WNneXWmv7/bDbgqTVv/S2M4EAc3tR/6F8T5Xm9RRc0yQhuzme3Q== X-YMail-OSG: hJb_qgQVM1nYB0yex0XCHNVT4W6xDefSLXz1peIvfCZZVvjFQ_EdUhUlYDmmkai OOIacIaNcAEej.eJm5vZKcGEZLpdcvIirwuEPtd.J9eFKsBvznWq_pzHCujoLhrVGPgU3UBKuvnm eCz31wj7g5jgpCW8YAoX7Ye8lw9_nVZl_xq6_nY6crAl8JBA9hHccxgyWjHhkdQz7YiRyGpvCvsz ZQJYJ_yMf6ZkWG7_hdi7x1v.Er1NGEolMgRL6e.gtE1iD5k0M0jdnL9_GsLWuSqZQrTRvHs1j_p2 RsLVd8vmX6cEGAG3riitB2Qd53gqjODwjPI8HP5s1HL4wgaG7E5rGMZWxC1gaLTDIErr.oIfauGm Wm3kW0mjRN_LbVFlV791GOz8XJkie1_nhURecx_3rFbKRKrl1yBSJiXsIYO.cBvhPM8QSN11gFM9 eHylIwz1V3lrCa2ofSjyMR96q0C8pZi5oahRV7zCqkFhnEJuzFFPEm_Yr1SsyMMwl5gaVCRcXsH6 3xG6fXEhF5ARI1dTqsaXppyl738d01SP41zkIQ1EPU5oyECi1FKTuMeKWNr9ohLeoxIx7R5Dc5io r8ExUfoL0n.oHGYQ.P_21DiHwXvdKXti7.Pm0KIhK2ITEME2OBIR0j1HKkf1NGM9HCHk_1ydO5.l d5nXcTvORmg7b0CRoBjOkTcSapB92EY9Mxe3WTp2_J7ZfAur0T2s.6N3RP6i3B6aqT6AvHNZJtTj Mrp5veg4d2.fwhfIdSkwYiDfXkincYIqYBnTkWzF8Z.ZXyKTUDCwonqXnZr64ZuArgl8gpxVZo75 _TELLMxBSOk8FjF4ZJyDg3m8674BAFo8tCRxHWP7i5iewYGzWLMpzkQ_HBPhW4G5EZWBEA1H5XMQ 8qLKQvoWL8mSglbbDt2wfRodiNAc2Vnt1yEWwz_F8H43bQmEtr_8e_QCtRrQk0LgBlizGRG_o1EO uAZQqFw_UWc_o6bGBlbeB3OTcGsEE9Ol5zDwVY_hFgSUH8H_zUxCou6FgTllNTCeiTZQMKt1JYHs U1gawuuB0X0PeTWrbwvXcaAjthoieWG76QShzjNcakamkOQfwfT3vYMmaDhNqkyfF1Hspvdpese0 OXOS68cAERrNVG7dZkJ4yDxbcKAFQXFiUJr2FNMTXUwfpKYcTsQvUtcfm.7dFMtLynmwv7g_tQ3w 4BI0Z0cxWJo_9zN0y3jYRKIc7lhLVzfwoyBwiOBvH34HqzWXSErNhLkvbw.m8pHwnmulZ_qEfcAi esXiacgPbe3AgdUxEneXJ9pOmYVpWUO88zvudOvdg9j_SRoWWi0nkw_qYw7cFtbnRIImLdgMpUae UvVLmO7aMFuhUKNVIhQORg9LcMBqPAPjiWQGH5doTO_SNlHUILq5lED9CJM1WbbZlKmANMWnkbGO j703kNICpl62FfAM0AplfNvOv4.CJvkTCsNPMDPSnRylhV2Ak7T3XBEOyVu1amYyJr3Ywr828qW3 aNKeeR.7La5rmNIQEMhnoTx0dzQodHCSh1EZ3MPaFxb1SwHP5F7kraBNhSXjswMKY2J.Kr1nVXn0 iAF9B69rj07Zbe6RXB5WSiuUbK3MByCwS.1RZr53idO5VwzY3WPHNtQNWLSVO.48qGiI4pXDTXww 1BZrF07bItftpYYColJKesCXFPQUVqwu8pBoGgEkb3VAqX2yDiHF8jJC7yydCiAuEsO2xV7oVVOu GOrf6RGNMkrq0yqqclXbM.K83hvaB5brR1rTgZwTuiZPND6jbTN6IVLNazFD1_pP_35GF0b0o6DG 6ipwjOeGQvK9XUfs6eHRl4H7.5xRrjLizhgHYc0uanYGIX1I4CI1iwVy3nZ4umPaad.z1OjgpclW xOhaN8K6JcwLRPMAvBZgWfRx8GbjWOrYZOzwnQ68sViMC7rzMbsD8dKXWkLO.mzmRcfvMAsWceM0 zMAXZt0bASxScHUiUkbiMtyf1KkgVkRp1FSlyfNEvO1Xn5ayQje5JDwZouAE22KMdXnM4yX9RsX. OU_ZDD6C_nd.4dKjApKwJcemOd2A3vYran5HVAbS0fQlBjEKE50RR5HvGXmywNB1kM2bmNvpQFk6 LgGDIx5MLQF4K2I7be1K9b2RdB1hiIhkLewkithnEa8GZMATTMgr3ZPFdhTffqiEFeQ45oxXz2S_ 7zCFf126_R5KSTlkfzxTCBFOZT2gejHQBwGU47Q4ZNtynp_O49JmApOgb8kXVpBodGZ9lQy4hL9k ttePm8GIpkTA- X-Sonic-MF: X-Sonic-ID: 429f1ef2-ee03-4064-b65c-1c3908ac7067 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 16 Apr 2025 21:17:53 +0000 Received: by hermes--production-gq1-74d64bb7d7-w6q4t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b8c20b2091e2380d84bec494f453132b; Wed, 16 Apr 2025 21:17:52 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: "Invoking IPv6 network device address event may sleep with the following non-sleepable locks held"; "sleepable after non-sleepable" Message-Id: <0DD42879-97C2-400F-BD94-12A36513B811@yahoo.com> Date: Wed, 16 Apr 2025 14:17:41 -0700 To: FreeBSD Current X-Mailer: Apple Mail (2.3826.500.181.1.5) References: <0DD42879-97C2-400F-BD94-12A36513B811.ref@yahoo.com> X-Spamd-Result: default: False [-1.10 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.31:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_SPAM_LONG(1.00)[0.995]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_SPAM_MEDIUM(0.41)[0.409]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZdDQC3Dt9z460d X-Spamd-Bar: - Context: An aarch64 PkgBase kernel and world boot under Parallels on macOS (M4 MAX): FreeBSD 15.0-CURRENT main-n276258-c5773d366ecc GENERIC arm64 aarch64 = 1500035 . . . vtnet0: link state changed to UP Invoking IPv6 network device address event may sleep with the following = non-sleepable locks held: exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r =3D 0 = (0xffffa000c0b3e480) locked @ = /home/pkgbuild/worktrees/main/sys/dev/virtio/network/if_vtnet.c:2202 stack backtrace: #0 0xffff000000530f0c at witness_debugger+0x60 #1 0xffff000000532140 at witness_warn+0x408 #2 0xffff00000069ede8 at in6_update_ifa+0xa68 #3 0xffff0000006cbcb0 at in6_ifadd+0x1dc #4 0xffff0000006c80f8 at nd6_ra_input+0xe38 #5 0xffff000000699200 at icmp6_input+0x900 #6 0xffff0000006b2c54 at ip6_input+0xf64 #7 0xffff000000613a04 at netisr_dispatch_src+0xd8 #8 0xffff0000005f58d4 at ether_demux+0x174 #9 0xffff0000005f6f80 at ether_nh_input+0x374 #10 0xffff000000613a04 at netisr_dispatch_src+0xd8 #11 0xffff0000005f5d24 at ether_input+0xdc #12 0xffff000000328ea4 at vtnet_rxq_eof+0x6f4 #13 0xffff0000003286ec at vtnet_rx_vq_process+0xb0 #14 0xffff00000031f824 at vtpci_intx_intr+0xe8 #15 0xffff00000046e0e4 at ithread_loop+0x29c #16 0xffff00000046a2b0 at fork_exit+0x78 #17 0xffff0000008897f8 at fork_trampoline+0x18 lock order reversal: (sleepable after non-sleepable) 1st 0xffffa000c0b3e480 vtnet0-rx0 (vtnet0-rx0, sleep mutex) @ = /home/pkgbuild/worktrees/main/sys/dev/virtio/network/if_vtnet.c:2202 2nd 0xffff000001129640 in6_multi_sx (in6_multi_sx, sx) @ = /home/pkgbuild/worktrees/main/sys/netinet6/in6_mcast.c:1217 lock order vtnet0-rx0 -> in6_multi_sx attempted at: #0 0xffff000000530aac at witness_checkorder+0xad0 #1 0xffff0000004c405c at _sx_xlock+0x70 #2 0xffff0000006a7a68 at in6_joingroup+0x48 #3 0xffff00000069f01c at in6_update_ifa+0xc9c #4 0xffff0000006cbcb0 at in6_ifadd+0x1dc #5 0xffff0000006c80f8 at nd6_ra_input+0xe38 #6 0xffff000000699200 at icmp6_input+0x900 #7 0xffff0000006b2c54 at ip6_input+0xf64 #8 0xffff000000613a04 at netisr_dispatch_src+0xd8 #9 0xffff0000005f58d4 at ether_demux+0x174 #10 0xffff0000005f6f80 at ether_nh_input+0x374 #11 0xffff000000613a04 at netisr_dispatch_src+0xd8 #12 0xffff0000005f5d24 at ether_input+0xdc #13 0xffff000000328ea4 at vtnet_rxq_eof+0x6f4 #14 0xffff0000003286ec at vtnet_rx_vq_process+0xb0 #15 0xffff00000031f824 at vtpci_intx_intr+0xe8 #16 0xffff00000046e0e4 at ithread_loop+0x29c #17 0xffff00000046a2b0 at fork_exit+0x78 Starting Network: lo0 vtnet0. . . . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 16 22:45:20 2025 X-Original-To: freebsd-current@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 4ZdGMS2p2Sz5tLpr for ; Wed, 16 Apr 2025 22:45:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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 4ZdGMR6vfGz3Lr1 for ; Wed, 16 Apr 2025 22:45:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=YZMW36n6; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744843533; bh=KtV4Dy5hVtN0BqxGfHrM2zSQgphhMNvFLES8EmH63xo=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=YZMW36n6KyJjsi5lHjsbRjTYXBNCceK5C/htq8hPtR51KZlIYw6bwgIPENw+fFhYDgyQ8D3624s+OAq6z7KV06YyMB89ht3WKTc2h7nW6jrci1ij56X5u/oI7SuEdum29DSMXCJ2CidNJbRhVxvGCBP5fKoBrdAdyrdLSUOewMfRTh5Os0iACE/X/ht/ly/1UzdlovK3nEoNSf4wwrUSkj1qHcsRtsow9kPOhawMM8Zckc2nevClCfXMOhD0K12zzMc2KOoiBm0bdThnqLErWCNiNt4p4aCJqcFWig7TAbi5cvKEg4Bk180Qd51qvqBfXj/XBSKZHNOwrDi1k8gJPw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744843533; bh=Dm0pNvL3ShQeGi2ybdK3Ek10bvLD7PKlajdBBEwtsVL=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=HuyjuX77UO+au29nz0Qm1ajWcmL7a4gPs+LpXSL+ktnocOL6vnVR/p+EtJguTOKyoGMqNXoMLRQD9rF2NIRrnDJPp8KUbjHVBssPMVg96UQIldDytbtdV53L4fVOk29qeiJkrlpwjFuP4jkw3SRE5m832r9Zwi/5WKDSAHk72ALy+zL33EdQIz96/cxdCekKX7uuy6JlF5pcgiHpC0ZfLzvD78nfiU5Ij2GlXQkfzLKayaqTGD0v7ud8xkoEUdmY9g8NVBZ2/zhYJskI5SrJt27N6kF7TTovuEFsQn2aYbjzPaAvDpcSA+OgH+3+oSj36XLGe76ZULvnbj1EJfm/Og== X-YMail-OSG: jHo3TyYVM1mSSMD.KbtJsmomj3rGZb1uPHVx5Otqy70gWlDUc1vg6N4goPjXNWi sErYKdUjNMIijXpmAObqafe4_5Wav89b2zDSbTKD5.NyMk4hho2XeBhbk678MaPMO2X6hMXa70I9 Rvi9H9XWR7EpUAQzAWI3Pul2FLURpSe_0qZXxCz7OCbaOMGar17OZcs9FQ5J_xLOSW6D2_vLB3AW nDRFK6Cg9GRGf5bJ_Dlrpk677mt7IH_ldwUndYuCEzyTNxMsIdSsvB4uGlCiEeWpWAbPpUtjGoXX Tiq5BwmWehiRDIa0sN3kB92HPPsWEUDHhrDhqdtYE5867w.2uPJpXgnFBuQWOOoS3TKVmNOKMtep xi6CbnoVC.lA_E96SGGN_wrQ0dT3OJ_tX8AQYVqdPF9hgDz0RFIVp5riuBRxqIGYQjcWos9HHg4S e82CBCL4LtzRXVhm8r8K.Gu4y75b1KSVCe8BcxJeEvRWnDngndJVHkXHwRQSqtDycj_cOj8O5_F1 Zal3qEvwaye4sKYAUoH2h83As26pVua5XVzpbsV3yS75LiFDGTlAb0_5gvAGfTnZNHxeY37YB_Bk bsmw4hatt3LLHoqVzZxzeRkHB5Tgm7d.IhVRIe6a.4P9tu3PYNCCqPY.mZZaNhyi13KPxFtRyK3A RJKI6Oq7OCeNry4u68bo.nDFu3Yv9KD1k5_rD6nN3wXx3UoeNGT6ODRds5OlzpTbU_TYnS0gr_4A Qfh2St.e4ZF3TqOsaSItGrMc1y5.jEksbsybxXO8MaPMdSsOSQDHjGC_thyr1FYXxCuyP31lM3mL 8j3.zr_QtHYhfmLLEG4tFSCV3ZBuSxTFNbLGI_.PHWjhQ6LNbi7Ic4Tp4pPqATAkyVCWn14poDW1 sj8rtkPYc3BbOZq39_7e6JJN8TFIR2cepH9bkT1Twuj7.87V8KdoDLk_qut_6Vwzqqh6o_Zdz4ZY qftPA6FXAzBLSGA269daqIwR0h50NXdjBWiSLc4IIFC37sSmrQiF8syMJJOPNYJ7iPZib6wnQCZ6 lJMjh7LAI5jK4Ksy4D4h5zdxGBYBQGeWJxQPy0c7tyMIqbJ8spQQ2aEvbY4H1A5n9zmrjRKkMvRY nnJ4tu4nGKlDOpxcn97gLVoe_H1J0YK8.7_Xznc82.Vm1hySfOQWYVS3Gtq_pDEsJcfFiDaOAzzn Ns2gR0ObZQm1Srdcyuj2n29k4sIpFZFmB.FP59n92NOZ0yBNEomkVtGztPMZ.GrBRC9rCTb_pj1g IAdHV7zdCTFf8Y2EjUaPHQaRjxSkpndhyrbTdGfby57Mb.GWOd_gRTilyXdDVwcVPHQFlWl69V.l trx9dRv_rnmcML9U1jPXbBf5GRsqzuS9pU.tlsEiDUS8f312DkW0YDdGylM2ZYcWlJmaBFkJ0aER xtW_bH6URslO_JjrlQP.oQmUVFePxhj9PCPbWc1J.5uknhGiC215opncCd1a1YHXbBcKoes50.5R qwhsDqvEFxhdQcNt4zHThWoO763.pL38s5pgXS150C6ObMaSmMG4t.prHn.ni7tf2ovPitIwVc7A TRmW2PL7teKIWlEFnMVH3CHmqQdpTn1H2_VAIZ12o_l5pe1Dzo9OWvFRmyHzx6_UmpNSvhBfH96G Bvm563a8GbQW_FikKZYkp01TxJYOeqylVLI9HgeRT9MAGxe5DTHoqh2Z.T9bmLlIeDUoNFnKXIMZ gEP6UgPIPnBFPx9gwbSfsQp1gO1_rO.OBKVYbmrMSjS4HOERDfNFSnuJ.Ulr7z1HciwMzHuHj5rT ERaKZHLzE.jjSCU6OnbIGLjI_.9Dt7QnTRR3qvpB4PNgJvN28Yy3IWrc21PTQ3QlisOyNUgh3DC9 NLqq8LNY4s_ZP_t8Vl.2E65C.V8W_0IUAxqMOM0wfN1ZLJgK.qsER9xZOHba5ocZTAj8cu2wLMeA KCN8KaZMe_dGz9oCYnvXiXur4D.J9JN..vHo3ZvF4.NJpvSqSllKeuzI2ZCH8Pta8WLS3_8tK.MG 54.jalfMEj9i24sPYpUnZI61fLvd_2u6vCMJfnOiRgYUD1od7vJqS9RJkume_R6UQpSCJqRB0tbH EqG1We._p.6t6t0jUPwQvCyxzHkY0jP2ZDpVoioILdInWLeDg79CsCTGMt0xOORfq2BJCh8Te5Bx ndr8Y3oLQ3vXKpneISv7tK7zyQuRzUF3kb31M8hEpajK4QZAx6efUs5UG__7xVMTwM5f.te2NiIA 3ppMjUydDS5ws2U7rHTvEBcmzh5fmzpLCBuDqmCAD0Gtr1_vOjVBGrMAa_mObjw8DW8SCBgRC7ad 9z4X5CEg- X-Sonic-MF: X-Sonic-ID: 591e51b7-338a-4ee6-bdf7-ede67e750d1a Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 16 Apr 2025 22:45:33 +0000 Received: by hermes--production-gq1-74d64bb7d7-r5xbr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ecda323ecc7aa313ceed4d92b14616e2; Wed, 16 Apr 2025 22:45:30 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: No GUI after 14.2 p3 Message-Id: Date: Wed, 16 Apr 2025 15:45:20 -0700 Cc: FreeBSD Current To: Mark Linimon , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3826.500.181.1.5) References: X-Spamd-Result: default: False [-1.75 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.205:from]; NEURAL_SPAM_LONG(0.97)[0.972]; NEURAL_HAM_SHORT(-0.75)[-0.746]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_MEDIUM(-0.48)[-0.481]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4ZdGMR6vfGz3Lr1 X-Spamd-Bar: - Mark Linimon wrote on Date: Wed, 16 Apr 2025 20:23:15 UTC : > This is a known problem. > > All package sets are being rebuilt right now. Due to an unforseen > circumstance, the first attempt to build them on the updated cluster > machines failed. It appears that this has since been fixed. > > So, right now, packages are (unusally) not in good shape. A few > days should make all the difference. Part of why it is taking so long is the unfortunate timing of the pkg 2.1.0 experiment. pkg 2.1.0 makes large poudriere "bulk -a" runs take lots of extra time. (main-arm64 on ampere2 has been running for over 15 days: 381:06:44 with 4930 Remaining as of when I grabbed those figures. Getting close to 16 days+.) This is being worked on. Unfortantely, a different type of failure showed up in the first attempt (via pkg-devel). The time-taken aspect seemed to have been fixed when I did a quick test but I reported a different problem. (Once a "bulk -a" finishes, there is is the time for distribution of the build to the distribution servers around the world.) === Mark Millard marklmi at yahoo.com From nobody Wed Apr 16 23:13:13 2025 X-Original-To: freebsd-current@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 4ZdGzb0rzxz5tNyB for ; Wed, 16 Apr 2025 23:13:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.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 4ZdGzY5Kztz3Q8c for ; Wed, 16 Apr 2025 23:13:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=X0pF01S7; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744845208; bh=duPfbrN1pXDBLR9tqhwQDCYzWynA+Sf1KJsRevjMzRg=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=X0pF01S7mLpowySCYvAfi1Z6qbVeO3J3WJUJ1I0rITsxC91Un/8y1OkCCxsSL5lYMomQjiuhEv3ueFTEmrRPbbQFbLh4U/ODVIKjilb5QKiAcVdpoiSZm3Hua+/4mMWI1WIRjyDE2SOF9nlzDMgJDq3yrG8Cpft+3Z63G0qn4mOy3UyQ3GskZ6zYlYi5+WIOQJSmEYXLtxvaqKRheDT66NZpl13vgV8LBvkh1p2qEkAMNNu5lIDJLkxtWRW0PKHccdk8SBH32hfMS14Elifh8HjdQ1mhaU5PeFDXBXQvWWCVub839AOHJRuUBBTHSaVddvQDkJ0TTcV/WPDAezKCSA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744845208; bh=g9WaySmEUTi0r0yzlDxie15LDMwSswlggymvUzRI5aX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=e9VK7ANTNfMo4syp+rDJp+YV0cWWQJ3TvDgg38OJRn7ObYvDTDryDV8TiSixbfCA2hED7r8rmbZslesEjNMgbVIf8Tw8BNHAmqypZwVZ6Y6cGxxCA570sQ2ACfaFGaKR25Vj8ejI/zL69bqtIB+VxafRRRp05TzSuZghTTjpc5ErtiVI3Oxs3eG9E8L7XEMZ5vbHzGQXN5bFpMFAtPROmItAoFZGj2xPjisFP+vANoIhZL3wrgYp6sQJqabJtfNxkL51Akm+rtRdI38dQ/5nprwo7gCflMuCGSe1J5gVBwLiQAjTffry1cl7vTIBrpsPeZ6FZ5XhkcGHgOxxb4C3Cw== X-YMail-OSG: CUCgjrQVM1mVE5t4EA4GoJJ4_G.38VmY9KbUaIquzs9RAzHFr9FOdK2UnCrDebw zdDgWfJ2Ik3VaDM6CRF86rEJEZAE96Aus_0coHRKbXR98BblFYZnH7ULJbfjmJPzQyv1DrDkjfx9 h1escnLJMjG4Vp14KvZKQcUcFDL8ItUtvGl7soOd6tS1ZCVb4dNQy5Ncq.o9XbkAmSW801pXU_R1 _mCEsyDjos810RpRcWgj2b7.mOFxbtr6gQDem5SuHg4FJcq.pJ9Ndvg1NEn9ouyPBjdgA5R3IRK9 5TDN4b6BO.baz24gm5UTvE8.Fx_leKflh84U5Px5Rf5GpOWgFF.jgwtZbtxKcAAIku0GpKhLzE48 z_00qjTmJHREi6lmLbkMQ1putyRgdE_8CNsx1u42Cija74RFdhif7x6eaphYQ4c5fwbOj01V0S1B OQILnQZveTh1UVWQt9V0GJibHCf6BZZbCE28VSS.ud61CGadQXXnfh5ZVmqyknHFSzNgGImjfApS mqqTOd3iyATDYmIVinkJ9wWDuL3Tsdm5OZCUCCj.HzgWDumfK8In7.vxru14jn4og.6dZtcM82LH 2CtFAKEhMtCwO2Qw7ABATZ_fC0FIYV3WtZGUsdyFrElNIhWLN.ec3Dueo7CkLvzKL7DnQnEPmAdm 4UCTlX0KRX74Qy9cJZbq_4sHdJWMz1NSvnh7zGTkDPJVQbarJJlMtDaUBi_LO_PGM_EXmMeIvlDK Ssge5wAQ4WapGMJ6GeD3kQOEYwtCwBNSOXOEA4_v.fPKBLQRRu.vMzJI7nThFycBY_8JWMsFCIk7 3oHo5EV1jIn0lSx5fNksmajhMa1TC_Vft7fvfGFcjpJcw8IWdUV1os36gGY1YRIskLiAJWUezVtH GTvNiaoPHhuzj0PtyezUUycMAspI4VnpSeHSvQNYKfSlr3B5D.WJDQE__FDjhX1fopvZVUw3j2Xk S41BFrADI7wO1Csz3K.9Y.uLoBn_3Yl.8ZhTvpvokkbWXw3FwNcHTBSI29rAdxF7Hm6yNaRS2sEw xZwzdxo8DWXTHUz6GzVtoQ4Dgh7XmDkaNGc7eL7xcZiJZ0l1W8MDhdE9oYJlDKdZS3XNK6S3mUin 80B7GgMw7KWuRAesj6rf7npm6xpbGNjEvbjxtOwin1Ht4BtcuLw94SM8W0XI2crRlBt6LVhxj7lg t9I9mpWDRTfYI.yD5xg9RFpvezmCrxVey3btyX4olK7..feDV1euAEfiWAYrirvqFQnNzl9GnoBb 7Z2LT7OLHDmvzyZWCbpWS7oTsXIWSu59A1CkCXf3aTNcez9ZB.nkTqIYlC23SpNwI29LwBYXm7lP zme9ybA4Cqm_clJFlHH_m4GjKp6bBHWKAxjgKZ.JOmKv62CZLd4.nTXf8fhbLMCPp19dkNzmbVZY u18k4feJ9gyPpa1IGa.319SnRt.DMzA.yKqpN1fBkesx77CgZR6ba6jYDdgQ8tEJ0rF0e9V7Hvr3 GLFE41IKPgqmiTv9LjpwVl3iW80QVpXQLE_B5Yqyz043cI_5EpBnWDMnzlQOGnPpJPD2zdSvxwRQ v_9jw0M6dYceen1DN6pmjeJIPFQ3l9_dfC_SamRIVfRc6JjzxIlmezKzGTPI5Ahqk8xGzHH0zk.z 2KddLma5zg5nvDKyZQTol3HRkv9D4Dm1R3qEC73Hpwvp7Y_vBk.TPU3HJ5FQla4cV6o4dnobdRpe qMKA6fhjilhiDw271Y8QRCUmDMiZ87m6kSSx.Z0fi8D7someWiMCKZfqCo_Vv1zacM5CDLElvrMx LBLqL9zl9_Mfq0YJyP1QqpSFVzFY8KwQHOdz.7OXw9_RvahawEPdGEJ9FvgKOR83EiD4uGj8fzJA Z8eJlNDIlcXdM2owAgBGx3iDlIt6deFL78U4QVuOhQOFvTQvtEG8IRLUzqNp7oRc9BzLlV50V7Fm FWNBX.hZg63d4jrGqqsG1lvZz8JekEZZ9z4JU_PcRsysslRw.WNxstjtdTawTzNKjQkTgH74mmV. _wCiL6yw3q37VxmYh6SZChRQQdlPfRQiLGKRMRoHK.iTs0MGdMiT3crF_Cswpkyr35xPiZjb1Egz DIU3YvKs0BHKxuupHxWPHUQgKNz4SYy1jbetcQUWQReckVon_Kr9DzfFnn53CbAwilOcoBj6KxcG 9cjsOE0vmIkZkMo4WayjmFGvFSYwIYxdUE_snvyDiLmq2yMgRRnwPVvMgv756olg5RSd.5y7ezn4 Z69Y4fj_CjXuP0LPHzu8faRDZhQsJFHfqq7_wk.8qa13__a.teIl0hGaHy47DBKwyVXA- X-Sonic-MF: X-Sonic-ID: 7be57506-48fa-449a-82b0-73d4bb03b870 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 16 Apr 2025 23:13:28 +0000 Received: by hermes--production-gq1-74d64bb7d7-k2g2q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9bdee6879cdc7552bef2b5cdd722482a; Wed, 16 Apr 2025 23:13:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: =?utf-8?Q?Re=3A_VNASSERT_failed=3A_vp-=E2=80=BAv=5Fholdent_?= =?utf-8?Q?=E2=80=BA_0_not_true_at_/home/pkgbuild/worktrees/main/sys/kern/?= =?utf-8?Q?vfs=5Fsubr=2Ec=3A3391_=28vget=5Ffinish=5Fref=29_=5Bmore_example?= =?utf-8?Q?s=2C_namei=28=29=2E=2Evget=5Ffinish=5Fref=28=29_is_common=5D?= Date: Wed, 16 Apr 2025 16:13:13 -0700 References: <267C2D6F-5E2C-4482-9CDE-7EF6522EAF29@yahoo.com> <87EF0A66-14B8-4978-B48F-F4DE8EE115C9@yahoo.com> <4DFF9B48-90EA-47DE-8A91-59C1AB30F3C9@yahoo.com> <19A813BA-A9EF-4336-B2C9-E6B4C12178F1@yahoo.com> To: FreeBSD Current In-Reply-To: <19A813BA-A9EF-4336-B2C9-E6B4C12178F1@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-1.62 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.64.206:from]; NEURAL_SPAM_LONG(0.99)[0.994]; NEURAL_HAM_SHORT(-0.97)[-0.974]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.14)[-0.141]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from] X-Rspamd-Queue-Id: 4ZdGzY5Kztz3Q8c X-Spamd-Bar: - On Apr 9, 2025, at 07:38, Mark Millard wrote: > On Apr 9, 2025, at 06:41, Mark Millard wrote: >=20 >> On Apr 9, 2025, at 05:05, Mark Millard wrote: >>=20 >>> On Apr 6, 2025, at 19:29, Mark Millard wrote: >>>=20 >>>> [Somewhat hand corrected "OCR" conversion of some console image = content.] >>>>=20 >>>> VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >>>> 0xffffa006e11e6a50: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cb40f0 >>>> usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 >>>> hold count flags () >>>> flags () >>>> lock type ufs: SHARED (count 1) >>>> vp=3D0xffffa006e11e6a50, lowervp=3D0xffffa004b074adc0 >>>> panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >>>> cpuid =3D 8 >>>> time =3D 1743988125 >>>> KDB: stack backtrace: >>>> db_trace_self() at db_trace_self >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x38 >>>> vpanic() at vpanic+0x1a0 >>>> panic() at panic+0x48 >>>> vget_finish_ref() at vget_finish_ref+0x1a4 >>>> null_hashget() at null_hashget+0xe4 >>>> null_nodeget() at null_nodeget+0x34 >>>> null_lookup() at null_lookup+0x118 >>>> vfs_lookup() at vfs_lookup+0x3e0 >>>> namei() at namei+0x298 >>>> vn_open_cred() at vn_open_cred+0x450 >>>> openatfp() at openatfp+0x238 >>>> do_el0_sync() at do_el0_sync+0x608 >>>> handle_el0_sync() at handle_el0_sync+0x4c >>>> --- exception, esr 0x56000000 >>>> KDB: enter: panic >>>> [ thread pid 8113 tid 163110 ] >>>> stopped at >>>> kdb_enter+0x48: str xzr, [x19, #2048] >>>> db>=20 >>>>=20 >>>> An issue may be that I'd not yet updated the world yet after >>>> updating and booting the kernel (but no ipfw usage involved): >>>>=20 >>>> # uname -apKU >>>> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035 1500034 >>>>=20 >>>> (That kernel is from installing an official PkgBase set of >>>> kernels, not a personal build.) >>>>=20 >>>> # poudriere jail -l >>>> JAILNAME VERSION OSVERSION ARCH METHOD = TIMESTAMP PATH >>>> release-aarch64 14.2-RELEASE-p1 aarch64 pkgbase = 2025-03-12 21:11:39 /usr/local/poudriere/jails/release-aarch64 >>>> . . . >>>>=20 >>>> The FreeBSD context is Apple Silicon M4 MAX under Parallels >>>> on macOS. FreeBSD had been doing a poudriere-devel based bulk >>>> build. >>>>=20 >>>>=20 >>>> I've no known way to reproduce the panic on demand. >>>>=20 >>>>=20 >>>> Core dumps under Parallels always seem to have backtraces >>>> that are like: >>>>=20 >>>> #0 0xffff0000004b9e48 in doadump (textdump=3D0) >>>> at /home/pkgbuild/worktrees/main/sys/kern/kern_shutdown.c:404 >>>> #1 0x6fa60000000e9d98 in ?? () >>>> Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >>>>=20 >>>> and the rest of the cores are like: >>>>=20 >>>> #0 0xffff0000008703b0 in ipi_stop (dummy=3D) >>>> at /home/pkgbuild/worktrees/main/sys/arm64/arm64/mp_machdep.c:342 >>>> #1 0xd2e9000000866b68 in ?? () >>>> Backtrace stopped: previous frame identical to this frame (corrupt = stack?) >>>=20 >>> Again during a poudriere bulk run: >>>=20 >>> VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >>> 0xffffa001e559fa50: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cd80f0 >>> usecount 3, writecount 0, refcount 1 seqc users 0 mountedhere 0 >>> hold count flags () >>> flags () >>> v_object 0xffffa00875bbe210 ref 0 pages 1 cleanbuf 0 dirtybuf 0 >>> lock type ufs: SHARED (count 2) >>> vp=3D0xffffa001e559fa50, lowervp=3D0xffffa0031f0b2a50 >>> panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >>> cpuid =3D 2 >>> time =3D 1744180482 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x38 >>> vpanic() at vpanic+0x1a0 >>> panic() at panic+0x48 >>> vget_finish_ref() at vget_finish_ref+0x1a4 >>> null_hashget() at null_hashget+0xe4 >>> null_nodeget() at null_nodeget+0x34 >>> null_lookup() at null_lookup+0x118 >>> vfs_lookup() at vfs_lookup+0x3e0 >>> namei() at namei+0x298 >>> sys___realpathat() at sys___realpathat+0xb0 >>> do_el0_sync() at do_el0_sync+0x608 >>> handle_el0_sync() at handle_el0_sync+0x4c >>> --- exception, esr 0x56000000 >>> KDB: enter: panic >>>=20 >>> Here: >>> namei() at namei+0x298 >>> sys___realpathat() at sys___realpathat+0xb0 >>> do_el0_sync() at do_el0_sync+0x608 >>>=20 >>> Previously:=20 >>> namei() at namei+0x298 >>> vn_open_cred() at vn_open_cred+0x450 >>> openatfp() at openatfp+0x238 >>> do_el0_sync() at do_el0_sync+0x608 >>>=20 >>> So it looks like what is common is: namei()..vget_finish_ref() >>>=20 >>> vget_finish_ref() at vget_finish_ref+0x1a4 >>> null_hashget() at null_hashget+0xe4 >>> null_nodeget() at null_nodeget+0x34 >>> null_lookup() at null_lookup+0x118 >>> vfs_lookup() at vfs_lookup+0x3e0 >>> namei() at namei+0x298 >>>=20 >>> This one had a v_object output line, the prior one did not. >>> Some counts vary. >>=20 >> VNASSERT failed: vp->v_holdcnt > 0 not true at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >> 0xffffa00a2a17ec08: type VDIR state VSTATE_CONSTRUCTED op = 0xffff0001a2cb40f0 >> usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 >> hold count flags () >> flags () >> v_object 0xffffa00a40b73000 ref 0 pages 0 cleanbuf 0 dirtybuf 0 >> lock type ufs: SHARED (count 2) >> vp=3D0xffffa00a2a17ec08, lowervp=3D0xffffa00a2a21f6e0 >> panic: condition vp->v_holdcnt > 0 not met at = /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref) >> cpuid =3D 7 >> time =3D 1744203937 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> db_trace_self_wrapper() at db_trace_self_wrapper+0x38 >> vpanic() at vpanic+0x1a0 >> panic() at panic+0x48 >> vget_finish_ref() at vget_finish_ref+0x1a4 >> null_hashget() at null_hashget+0xe4 >> null_nodeget() at null_nodeget+0x34 >> null_lookup() at null_lookup+0x118 >> vfs_lookup() at vfs_lookup+0x3e0 >> namei() at namei+0x298 >> kern_statat() at kern_statat+0xf4 >> sys_fstatat() at sys_fstatat+0x2c >> do_el0_sync() at do_el0_sync+0x608 >> handle_el0_sync() at handle_el0_sync+0x4c >> --- exception, esr 0x56000000 >> KDB: enter: panic >>=20 >> Here: >> namei() at namei+0x298 >> kern_statat() at kern_statat+0xf4 >> sys_fstatat() at sys_fstatat+0x2c >> do_el0_sync() at do_el0_sync+0x608 >>=20 >> The *statat() are distinct from the prior examples. >>=20 >> Again the common part is: >>=20 >> vget_finish_ref() at vget_finish_ref+0x1a4 >> null_hashget() at null_hashget+0xe4 >> null_nodeget() at null_nodeget+0x34 >> null_lookup() at null_lookup+0x118 >> vfs_lookup() at vfs_lookup+0x3e0 >> namei() at namei+0x298 >=20 >=20 > The 4th one is another one with: >=20 > Here: > namei() at namei+0x298 > kern_statat() at kern_statat+0xf4 > sys_fstatat() at sys_fstatat+0x2c > do_el0_sync() at do_el0_sync+0x608 >=20 > like the prior one. I mostly stopped using the debug kernel in contexts were I'd also be doing non-trivial poudriere-devel bulk builds. However, when I did try such I eventually ran into the panic again. I've not bothered with adding more dumps. I've no known way to, on demand, reproduce such quickly in a simple context. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 17 05:06:35 2025 X-Original-To: freebsd-current@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 4ZdQq74qM6z5sZSx for ; Thu, 17 Apr 2025 05:06:43 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZdQq668q7z3vbR for ; Thu, 17 Apr 2025 05:06:42 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ultimatedns.net header.s=mx99 header.b="ScvKOy/h"; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53H56acm008023 for ; Wed, 16 Apr 2025 22:06:42 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1744866402; x=1744867002; r=y; bh=UzeLV9pSU+2WHDFyWDhQVhQwqEOH4fIkVT4l3uy513k=; h=Date:From:To:Subject; b=ScvKOy/hXQYWyo484gF0yE1XvqyPX198XNgOP6S3eJFWVJBq2ZzsPtAvJISKtQu/3 WFt9xaKNLczeI3VbuF7IdjKgiFcTUr+/OmuHE+87x4lp230MySsAkoBEzMRyTtiNcB j/VM92sYMRJ3/hZ//fhvwFh1w02GHFo/paNfl6RLDc1gaeXrqivDj7fmZX5aCo/Pmf gQq5MJGuFodEUhQwkio+7T5E7562AkpJ/Qc1//Zss0t1G5tuxFA1yIx3yp0f6Q2ssT bhQsy2cM23WNrQ8d8dD9h1mT6C2ciESlcIVStAf67NmC260Kc48gVXmsgh/KYTvf1V UXhUDG8407fdQ== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Wed, 16 Apr 2025 22:06:35 -0700 From: Chris To: freebsd-current Subject: /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error User-Agent: UDNSMS/17.0 Message-ID: <02a330977e072d6953ebbd4f464b44bd@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_565e0ab9fa55dbde3127f3d647818822" X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [-0.20 / 15.00]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip4:24.113.41.81/29]; R_DKIM_ALLOW(-0.20)[ultimatedns.net:s=mx99]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MIME_UNKNOWN(0.10)[application/pgp-keys]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[ultimatedns.net:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4ZdQq668q7z3vbR X-Spamd-Bar: / --=_565e0ab9fa55dbde3127f3d647818822 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed In an attempt to take advantage of all the work done on iwlwifi recently. I pulled a fresh copy of src at: commit b836c229aa5ac345114f5986b6034ad3ed760da1 (HEAD -> main, freebsd/main, freebsd/HEAD) Author: Andrew Gallatin Date: Tue Apr 15 19:37:06 2025 -0400 and proceeded to build world/kernel. The buildkernel stage stopped at: In file included from /usr/src/sys/dev/imcsmb/imcsmb.c:52: /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error: 'smbus_if.h' file not found 52 | #include "smbus_if.h" 1 error generated. I used the same kernconf I used for the kernel I'm using now. A trip to /usr/src and a search with find(1) confirms the file doesn't exist. How would I best proceed? Thank you for any direction on this. --Chris -- sent from hardware written from and running on FreeBSD --=_565e0ab9fa55dbde3127f3d647818822 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_565e0ab9fa55dbde3127f3d647818822-- From nobody Thu Apr 17 05:40:36 2025 X-Original-To: freebsd-current@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 4ZdRZX19hnz5scT1 for ; Thu, 17 Apr 2025 05:40:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4ZdRZV3vv9z3yp5 for ; Thu, 17 Apr 2025 05:40:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=JuCMYhT0; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744868448; bh=A5owdgxf1ZDJkQixV4dpak61mo1wDMT3KvOoF+nYAkk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=JuCMYhT0MYVWYT/OgnNhnooRO896BPbFpR6idY9rxv9VjOeVKrvTjJ5VM9kFXuhxXxUe+hH9pYA65oYKAkdy5eKDU1JltM8xTnpm+0Cta6u0tg+gs4N+/n5A3elGEks55brLUB7LUX+VLUlcNS0JQFT2QIypUDcDqoFI9F/OfocwtSBLI4SLiznIWnEMc7Z7ZjqpQpR4lPjuOQ4PieuU1zf9Uil3Sk1xreEpnI/RaWHUNaVmAhbvuBWDtTDpcxH1BLKF7apRoq4sf/ojeQzGtPZdsAnO2jyFeKdQGr9uT9nNFHCtioBovOBWw1N9xBLJYviBJYU8sdXjPywp/FfO4Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744868448; bh=eAcm6d/DXAZUyNvyAIxLIh7t03vOqOKE15gVMhXmss1=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KHv8jLImKOw5Ah+DkGV6e7fSIAh/uGCDl277FiQ9YkjKtq6SjISSmUhjdrpKPQMRCaq3KV3+OT/94+PJ/w0sax2iAv3cD7l2VUpiI267jXfbod8mZY2o/92MW4lBySG1AsL4f9B7cTMlkPhnysuXKfrijTPKBkXguxWsNVvm81HiWPvM6rFkPlWQXX9P/3grpmf1fWtv97Y/LUni7EwGi+f0bSjTDzUXlARUnHHwNEXtOiY4ITUjROnmFk4ep1+t0AfudS9MdEDyD44c1b2upY9E5NIudc7Uz+URmJj3p7AEfIvaNGr0CcWiLavx/DyZGABucVzRbLsSVvL9nxTFkg== X-YMail-OSG: wzp85hQVM1kKi8G6JtF1tNH8EKlVdnljf561DUvK_0uhrVn694btoWj3ex43rxr XfWNdHeFy_5tDiTVSzCmLPmF7PRJe33irYILaQgdu7dkWT6lEYQVeUNkMPYX.ipDigH6EcOcpgUh sGTdns6TQsDfeaWgD6ZdZuBGJD29b8A05_GRscdinQQx0K7dnJUH2HGpHtnq1jZCtrCPqgLyP6h0 bINaNvGmkJgi4BSdBvrfiI8lpNbpEPAw1D2H5LBEmc3cg_1QJ0QZ.Kf5T63QYpoDdL33UfI7HItL zbeQlDDVRmEbe1X4d0XE1vM_AmlaelchS9wiGGFo2S.48tj2uARA1L22VoKONZvqXOCWIpFjWT6o eCgI85cApHZEbU9HXnQjJB3JwEd2pmEhPOax_Vs2gGz1JnDHvNI1ANw8blSqc1Wg4MtHewkXdvzQ .vGRzyZMzwf2.LpOGDY3if8pxIgmkN23fCve3zDKzDgZF9RUU_sZMQ7INpc20QVW.JFWui3tXJ8Z Wpf8ixeZjHYlSdSojDqIWA6Fiw2YtKJkoLTlwsnizk_79_uSjJZIEifE1ho8frZTLdK9EK7hwBbc 0iVSUfOfUXsWNjlkUEL.hhRgPW9F7lKKw8tqM52nWk6Ry5lU9t3km3fm9auXvS2z1Uz.S594C5oq W9WHBSBfdVp0AUkYIEZo1ubCz.Haunlrj38h1KCF2zwhGEouuuU.m7J7PP68GOlaZX5DMhF0gOxE IjNVlV.LjcuZWEV7KLKPGPun_E8LGXT147kqNX33LJ51JqykD9qE0XxCgSb9XlYjkT6Umkn85CWB fBtxaiMoc4YTKuE7fvRQ40WefHOx75.itqRTXxiU5NE7.XcBAbtBy0veB0hUcVFdANHMgl8bXxUm i9nQzxc7QN1Vp323fFmt63_Z9PM_6dj1.fZzQ.kHdnGIP5l6.c3A0Vh6wESLpEGtf_UcJ6w11lan B56qvpSwCNm9yyVaxsdkflyHjcBCUczDr9FoqMgMQKaRmYEzPBytiOAFZb77NBCsH97K7iZqDZXE 6SUwwSnCupHzN_XAkiQr6bbifYwipr55jMJlyN6Nr8YAXTeyjbsbSNDNywZNKs5akr43VutXX6qe xwY.A0xXqNffaGllw.V3O4.GHB.sfqx08VrIfJvyQNVe3TSjnLxCfSrWQymPzDII9g1F_EqhRwr3 NAsJ60Q.3_0ZHcoW_cNt6wbFtnQ2rRJNqIGl1devkpO6DBE2NrXMNFJfODh2VgeYeY7jA6n6Bhk2 vQr8XI3pfMy1DvbRWBKJTkNkMKZJZKAO83_3cwJovqeTzumMUze2cx09qSAfkqvLNZoxP.zYrEMT k58N3tYTlrSRvWrmmuUzbzzhXasY6n5HWHJmB4qWyzOiUPnLLYaPZTtpcfsgO9eLWpZPgKBFN_tC kAvE_42Hn3PGe2BDOwIe0bB0BwITNik1FPybqwWrjt3ak_jEGkyLkHHNc6cWDgTfDWSYbCOq8wo9 yijk4nWLMfdxbiSu14NpIlplG2x2Q1DVlzY0EgvIl5JyBudYNtCm.RMPBdhscPK_jJkNd84pzIKy 9hZjskw_SQhIci_lkzT8tbOjk7IoIt4vq5qwWUvo9v1W2zbzw5ZJqJ3UHICucVdZItS.plNQtOTI iJtytr7yw8Nplrlhdg242iH9Y1XqXIo1HeUOfgkJjFk9DuRRyCSqahQ9OHK_VJoF_kiCEBWfnyaG _nc6eGNsmBA7LhBNRzQfVpzQkPp0jg5YqfZ0lSRs.m6kIA1rWkz1ly.1U5Wzr.f6jW.N9CUX.yTD LCBL_FAOWajKRVd0Ep2RHKOAh5xL.9CY2UCBbnylC.CzBrDtqQLCi6UaTgmCat3PC7CInUprr4dw EBB3Fn8Xy35F5II4lVWkcWTnfd.Rwm822CwC9s9ZIWpgwd2ZZyqoZu1jTXVeXA.aolmjH7KPsFR4 gDfe5D1EGoJiKNPS2fnRaeR3BLpjEiZed1C.C7mzRHFfCaoiBcjRsd.ywqN.BcPgtezBQdNwlBgC OEmpi31OUZvwrtkAKq8CbIn2T06ImJ6XP3wywsmb8Y4fJp14WEvQHrVm5zXRFevUVS.YXbFxI1eP YDded1_MMsT46eIDh4Jx56mzcjNVlSFoaurJf7swh4l2l2MC79sCkQzoMRJBXDutELGXI6TfTzDr uXm7rE8xeW.T2kv9iJ1ZC3zYqQ_GKHmieMoEvBpSPatQcmrsmBzQfLTj1Le7twLP97CmOvXR8y91 rZHL1R2Tqv7ziLb_M19ocgEUGnBVP3qqWra4KpLkm4KcGZ_M89q8R63TttNzNCNsdI1gCAAYFtKv sz2n9QkChpTun4xM.s7dg9Sui X-Sonic-MF: X-Sonic-ID: bf437ad4-9cfe-43be-82cd-6c83049ebacb Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 17 Apr 2025 05:40:48 +0000 Received: by hermes--production-gq1-74d64bb7d7-cmxx8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 361a463e5cb69d622609a3f20697b30e; Thu, 17 Apr 2025 05:40:47 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: RE: /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error Message-Id: <8E088E3D-2617-4B0A-BAE0-E9199DDA4F1B@yahoo.com> Date: Wed, 16 Apr 2025 22:40:36 -0700 To: bsd-lists@bsdforge.com, FreeBSD Current X-Mailer: Apple Mail (2.3826.500.181.1.5) References: <8E088E3D-2617-4B0A-BAE0-E9199DDA4F1B.ref@yahoo.com> X-Spamd-Result: default: False [-1.37 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.64.146:from]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_SPAM_LONG(0.98)[0.984]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_MEDIUM(0.14)[0.144]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZdRZV3vv9z3yp5 X-Spamd-Bar: - Chris wrote on Date: Thu, 17 Apr 2025 05:06:35 UTC : > In an attempt to take advantage of all the work > done on iwlwifi recently. I pulled a fresh copy of src > at: >=20 > commit b836c229aa5ac345114f5986b6034ad3ed760da1 (HEAD -> main, = freebsd/main,=20 > freebsd/HEAD) > Author: Andrew Gallatin > Date: Tue Apr 15 19:37:06 2025 -0400 >=20 > and proceeded to build world/kernel. The buildkernel stage > stopped at: >=20 > In file included from /usr/src/sys/dev/imcsmb/imcsmb.c:52: > /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error: 'smbus_if.h' = file=20 > not found > 52 | #include "smbus_if.h" > 1 error generated. >=20 > I used the same kernconf I used for the kernel I'm using now. > A trip to /usr/src and a search with find(1) confirms the file doesn't > exist. How would I best proceed? I've no explicit use of such but when I looked on a system here, I found a imcsmb/smbus_if.h inside a build tree from a buildkernel : # find -s / -name smbus_if.h -print | grep imcsmb = /usr/obj/BUILDs/main-ZNV4-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC= -NODBG/modules/usr/main-src/sys/modules/i2c/controllers/imcsmb/smbus_if.h (Some of the naming and upper-level path structure is unusual. See what is normal in your context.) So it appears that sys/modules/i2c/controllers/imcsmb/smbus_if.h needs to have been built first and that a -I PATH or such needs to be used to find the file. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 17 06:46:09 2025 X-Original-To: freebsd-current@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 4ZdT225H7Nz5shSJ for ; Thu, 17 Apr 2025 06:46:18 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZdT222Bhpz45hv for ; Thu, 17 Apr 2025 06:46:18 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53H6k9w7006838; Wed, 16 Apr 2025 23:46:15 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1744872375; x=1744872975; r=y; bh=RMilE+mjjIpC3ziNN1gkRA8Cq/6vBDB8rx+DdEjOgW4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=p+Vhwzl71jQhaSFOecYWw3ZX9HvhwYnkBlrGooxE69DxCf1pgysOKT3gm2lu4E5vB K+scDVlfAxTZYZfnm57rL9guBEcZDTAScBbTWGB/a1N46ru0AecZ9d+x08DiVX/JOv YA4puiavwOH0/ASjwHycm2xj+6cw3nZUe3aTg6Kw/07MOc2uRDHIdiW0mXPohTjMak lvISeL0kCtQ3kNerYXkFTRzx7cvgy56hwGbFPdVaSaAA/ncjkYLdmUBnSqjIGiOyO6 ku+YFM9/K3oDzYUs3VGJuJBCR9IeqNglKi1Todotf7XdsgkLpaiPxm4aJfYqbg5oFe CGuUzEhadS6Vg== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Wed, 16 Apr 2025 23:46:09 -0700 From: Chris To: Mark Millard Cc: FreeBSD Current Subject: Re: /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error In-Reply-To: <8E088E3D-2617-4B0A-BAE0-E9199DDA4F1B@yahoo.com> References: <8E088E3D-2617-4B0A-BAE0-E9199DDA4F1B.ref@yahoo.com> <8E088E3D-2617-4B0A-BAE0-E9199DDA4F1B@yahoo.com> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_7c498b2af90db134b83905a4682b5aca" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4ZdT222Bhpz45hv X-Spamd-Bar: ---- --=_7c498b2af90db134b83905a4682b5aca Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2025-04-16 22:40, Mark Millard wrote: > Chris wrote on > Date: Thu, 17 Apr 2025 05:06:35 UTC : > >> In an attempt to take advantage of all the work >> done on iwlwifi recently. I pulled a fresh copy of src >> at: >> >> commit b836c229aa5ac345114f5986b6034ad3ed760da1 (HEAD -> main, >> freebsd/main, >> freebsd/HEAD) >> Author: Andrew Gallatin >> Date: Tue Apr 15 19:37:06 2025 -0400 >> >> and proceeded to build world/kernel. The buildkernel stage >> stopped at: >> >> In file included from /usr/src/sys/dev/imcsmb/imcsmb.c:52: >> /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error: 'smbus_if.h' file >> not found >> 52 | #include "smbus_if.h" >> 1 error generated. >> >> I used the same kernconf I used for the kernel I'm using now. >> A trip to /usr/src and a search with find(1) confirms the file doesn't >> exist. How would I best proceed? > > I've no explicit use of such but when I looked on > a system here, I found a imcsmb/smbus_if.h inside > a build tree from a buildkernel : > > # find -s / -name smbus_if.h -print | grep imcsmb > /usr/obj/BUILDs/main-ZNV4-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/i2c/controllers/imcsmb/smbus_if.h Performing the same here returns nothing. In an effort to ensure adequate space prior to the build. I clobbered /usr/obj. :( > > (Some of the naming and upper-level path structure is > unusual. See what is normal in your context.) > > So it appears that sys/modules/i2c/controllers/imcsmb/smbus_if.h > needs to have been built first and that a -I PATH or such needs > to be used to find the file. Really appreciate the clues here, Mark. I'll keep investigating. The build worked last time with this kernconf. So there must be a way. Thanks for spending so much time to help! ---Chris > > === > Mark Millard > marklmi at yahoo.com -- sent from hardware written from and running on FreeBSD --=_7c498b2af90db134b83905a4682b5aca Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_7c498b2af90db134b83905a4682b5aca-- From nobody Thu Apr 17 07:19:43 2025 X-Original-To: freebsd-current@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 4ZdTmx64JXz5skLm for ; Thu, 17 Apr 2025 07:20:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4ZdTmx2ppcz3GM8 for ; Thu, 17 Apr 2025 07:20:01 +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=1744874399; bh=ZHoaThOpT4KA7d9MKejUlv7411CbtvQMoDgTHzMWP4g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RURto7eoFIjmMwRsttCnN4Lz4OylNWlfSbzJZkOywDzd9voi5MZtt2lO8XHsCntL+JW2cCuiRFAtina+s26n+JS+mA78leSXrOiWZSVFWJhY9yTLejfo9cJfgzO1u0g9UPwp1WdIzO+fXQatXqQyEzqoIdMRqt8JQStnDxYuThfJYGnHlcOQnvN3ns9NykVxLeQtZ4iYjVbQ6sEGsSRw+fNuMOKjeCKE3h7Vd9s/5WzGCw3Kcr46Y/pM47bV3mOvkAHQnSwz5tzZ4LnnWO3h+xmzgiOgO8Aa93VkuHShulU6lhW4YJJInLD1RcCCHNYuZTdhdys6iSGoN+KSEo0gYA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744874399; bh=1ihQUn2k++LvzU7p0xNwdhJCR+qwlgvkU6Aw6V63fmR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mXMElLRUqZ+Xpt1gLmGpeDeZwIm4TbyUkKhhR46ASAvNLlIw56RWwtVLTo7N+b7ejBmnVRel8bKw0rLHRfBpgq9fXwzvJqvEo+Pgts8jUDH68m7SMigTybJ8xNVxRKvdNF1MZX0UlnEHlDeKA+YNm+U/LkYS9y3S6ypJAqR2yTPDWqVVxtwBCn9fsyQfkkC6q5WilfV9QQ4UP7DuXlAvXpgeIcBeubqLSFCgEBTh2L904uVKvK1vdsUJ/YvFfpHZaMkOm9Ofp3XRvB53IkcixjsAPFWnFESFnmKPkLIa0TTFHFFC0OG7z+t6WBZJn1pdMs/Mgrh9sFvRjBTf06IxyQ== X-YMail-OSG: 20XbhQgVM1m1XZ4aQyLXtlYX9InNX7d76uKgrNVduCaBZrNpCBe1rT4PRXUEjOj clXwh8p6i4xPxsoSyG7egLmyhzPpcrJ3_ih1ysBY4onEVbpVXWt3w3637Ab0lslOQypSf89hrFyZ 12s2L_HN9BWnv1hEHgZev4LxuHtelps5f1281Lr_cYvP4bO7m_QdWU.QuoOrymv3PFLWEA4vZcAD NkMqVxGIEqA7KxCufNMANtvqyotw6Mdx20MqdeuU5o9XUoG2_pl1Yvo7UXY2qpTg7DrHtUyYjqgI 6TqwnkaSB2inprdWyvm2vGI4s8uutzcrTWVhb_7qgE22V5t84LAkhU9uePtxig5V6eHsM_8dqDkA tQs66hQk7xOvwq8ubV2DB7rxgeNFKEzYpJlFmhMMrkv.3SDbTLDrlXd40pYeEWgK4Th7zNGjWGZq YwpoBjtjK4AYJPow8CiwrWEadUPmdDERUi16wH7bPrbhMJrzkKR7Q6Ef_B0gd7ivHAYyPIgt_FGi FBmTkK1BJdLTbGyTIctP0o61Z2mUT8G02XPjUtVhJ8aVyMRiwZIYgm_hkaTikjvo8us2Isi11YWA 4XQJsrgzMNJlMPwfJLBT313UwEIGM1EcPSvrdpP.SD85ylad6fqL5jvNDlmv28kXa0hjo_lv1lye lroNRWHsGuh6u3fejdfC_dl69wj7APc0MEKsXG6gLn6rlMUR8hZwOu8Dfq_edfMq5mbowrlkGNJ3 lH1nCMiH9pzsNJkVtLDK.2EHxqBQ2ne5I6wg3HopZFN66VW_p5XnYgW_8.K3hqkl9njBw9fLIp9e y5AWSR0jwEgqD428gnVL0uGtOM8OAycGerxNlsUSFgb7sOl4traSwSSnopMc_mBBSXC0nOJrd0SG dTyXKlP2ny2oiEytAswBi_j6hghaOEORzlXpvlRo8g7gJ4jpj9mY0BXJXt1hHo47xd8c9lgN_.Sl eNm2Qcf55GD9Xnzwlror1roIFwqCkkMqnAQcnYrOh6GkWFnLvrPWkJdjS8.Y6Asvn5D16QhHvb4U _4BakrzenzCp.lCm.IU4Y_kASs_KYQJYCFObHEjJE_qjRCBMGqDFqwrtXsYsA4_KYn1UKquf_lHp cABQKBpfd0SjLRiCIhpPDEVQweThsTIowBxPfuZG9oJUpYfkWmU4Apj_I6kFoyQlr7VsM8f.9JMI ZPYMCofTUyS4_awcODiLmITw.8BHE51wyXu934y8IRf4a6TCxCpuyPWwU9WNGAmU7xNIpDl2K2aC QjndvenMN8BJUppdPXYY5Tx4krr6zUWFgYC65RYSMxjpxkFsxry5Cl02U1cWQaX.hbLhsNfHWUeA FnDdVtKWJC_Fqd.5xagHMXtrSsYM8pgB5GgBBV3_l3_CsU8cPMequwSkh8tBK7FOKEu2IskEZze9 tHQk.gSsYVALEt8LkVkRVVbZwW1Z0Zvnp1mlQuSUW4txQw5rKfJy0QZ1R.P3ZIzs8.m372uhR3Sa 7DgVBbZ2N74Qqf95r7.M6YkNRvbrmDSEDv0pwKfKL6mfZ7xGCidCfAWQWyRtDMJRXxPLmjuvwnDq adJs0awhd8z2NFXCq_NQ7XpTyHiFM28J9Y5wmMf8Mx_LKA3teL1S1cD1VL4LZcxW5lSm.FCtmydR RnBCflnvnrnoTD5tCg_LgR3X4O0nvpW3lM9hiwBfQDTecskHz89K9iyk.MfIde3XEc74D3MEzXo3 NPbcCaH.YGGf.oUWTZkq3JUSPGj6bU9K7FhhKc_v.kJtlRrL33u_BkEdEl.dWJS9cuBVfSg9H4NY acxIn3cZX4VfFmluqcoWWT6JR5WKMg4bHjdZHBOkaVx8KadirjT6Md4h69WmR2UsMJ.E_gLMvkfI ryGqUDwpk6K8IPk7gtE4K11dW77RNA3QfVB0NdeBV8uLAYJlrZU.9FQl_Putp1k6Vfxft6TnSGol ONa9fQ1Pptk57jogU28TNhGkJ1mDqRxe82B2CsJj99TKtT9uZj0ydwkeZuTlxZHX7pkjAN6eEZTK 6HEBe3MkmGneG1S0WX.CaiTj66CrsZ8HdO75eAlO8OppYphqhsEz7iNt2WaYeZKIWm.TIeM1W.BC e3aS_nAvDrkiMc43zM8MdaJnC0aKMBmRyMWfZ8BryvVTPIilrRVr.EBxPpDjjPZBLnFOgFa4ddJD 3V4SSe0WiUmSw.tMPt6ee66MqtMfGyfGMhgPbKqTgCCDcOVVg0QkEXjEmEZO0DHaMaZIqQFBP7wG g0PFxEQNYyK7THxJEZqNQHsyuQuZshmeyHNzJZaUIJn07r0yKgBCYUVotDBv1DJmacpNfr2OZIzz 4jV9.6LBurWqlNGzllggRcT8- X-Sonic-MF: X-Sonic-ID: c8e3e535-f771-4b6c-916e-caa6a5fde270 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 17 Apr 2025 07:19:59 +0000 Received: by hermes--production-gq1-74d64bb7d7-fddgg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 61d602abc20eef3d53a8d27d2e63a6d1; Thu, 17 Apr 2025 07:19:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error From: Mark Millard In-Reply-To: Date: Thu, 17 Apr 2025 00:19:43 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E088E3D-2617-4B0A-BAE0-E9199DDA4F1B.ref@yahoo.com> <8E088E3D-2617-4B0A-BAE0-E9199DDA4F1B@yahoo.com> To: Chris X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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-Queue-Id: 4ZdTmx2ppcz3GM8 X-Spamd-Bar: ---- [Note: Your Email handling rejects my Emails, probably because of Yahoo being involved.] On Apr 16, 2025, at 23:46, Chris wrote: > On 2025-04-16 22:40, Mark Millard wrote: >> Chris wrote on >> Date: Thu, 17 Apr 2025 05:06:35 UTC : >>> In an attempt to take advantage of all the work >>> done on iwlwifi recently. I pulled a fresh copy of src >>> at: >>> commit b836c229aa5ac345114f5986b6034ad3ed760da1 (HEAD -> main, = freebsd/main, >>> freebsd/HEAD) >>> Author: Andrew Gallatin >>> Date: Tue Apr 15 19:37:06 2025 -0400 >>> and proceeded to build world/kernel. The buildkernel stage >>> stopped at: >>> In file included from /usr/src/sys/dev/imcsmb/imcsmb.c:52: >>> /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error: = 'smbus_if.h' file >>> not found >>> 52 | #include "smbus_if.h" >>> 1 error generated. >>> I used the same kernconf I used for the kernel I'm using now. >>> A trip to /usr/src and a search with find(1) confirms the file = doesn't >>> exist. How would I best proceed? >> I've no explicit use of such but when I looked on >> a system here, I found a imcsmb/smbus_if.h inside >> a build tree from a buildkernel : >> # find -s / -name smbus_if.h -print | grep imcsmb >> = /usr/obj/BUILDs/main-ZNV4-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC= -NODBG/modules/usr/main-src/sys/modules/i2c/controllers/imcsmb/smbus_if.h > Performing the same here returns nothing. In an effort to ensure = adequate > space prior to the build. I clobbered /usr/obj. :( Do you have any paths that involve: sys/modules/i2c/controllers/imcsmb/ ? Do you have the likes of ( you likely have /usr/src/, not /usr/main-src/ ): # more /usr/main-src/sys/modules/i2c/controllers/imcsmb/Makefile .PATH: ${SRCTOP}/sys/dev/imcsmb KMOD =3D imcsmb SRCS =3D device_if.h bus_if.h pci_if.h smbus_if.h \ imcsmb.c imcsmb_pci.c imcsmb_reg.h imcsmb_var.h .include # grep -rl imcsmb /usr/main-src/sys/ | more /usr/main-src/sys/modules/i2c/controllers/imcsmb/Makefile /usr/main-src/sys/modules/i2c/controllers/Makefile /usr/main-src/sys/x86/conf/NOTES /usr/main-src/sys/dev/imcsmb/imcsmb_reg.h /usr/main-src/sys/dev/imcsmb/imcsmb.c /usr/main-src/sys/dev/imcsmb/imcsmb_var.h /usr/main-src/sys/dev/imcsmb/imcsmb_pci.c /usr/main-src/sys/conf/files.x86 # grep imcsmb /usr/main-src/sys/x86/conf/NOTES = /usr/main-src/sys/conf/files.x86 /usr/main-src/sys/x86/conf/NOTES:# imcsmb integrated Memory Controller = (iMC) SMBus controller /usr/main-src/sys/x86/conf/NOTES:device imcsmb /usr/main-src/sys/conf/files.x86:dev/imcsmb/imcsmb.c optional imcsmb /usr/main-src/sys/conf/files.x86:dev/imcsmb/imcsmb_pci.c optional imcsmb = pci >> (Some of the naming and upper-level path structure is >> unusual. See what is normal in your context.) >> So it appears that sys/modules/i2c/controllers/imcsmb/smbus_if.h >> needs to have been built first and that a -I PATH or such needs >> to be used to find the file. > Really appreciate the clues here, Mark. I'll keep investigating. The > build worked last time with this kernconf. So there must be a way. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 17 07:45:01 2025 X-Original-To: freebsd-current@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 4ZdVL95fBqz5slq8 for ; Thu, 17 Apr 2025 07:45:21 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (3072 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZdVL923Wkz3LbC for ; Thu, 17 Apr 2025 07:45:21 +0000 (UTC) (envelope-from garyj@gmx.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1744875919; x=1745480719; i=garyj@gmx.de; bh=65Q4XUHI0CRNfQICBdUm1nQUipjoX0uPl7BYKvBhOIw=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:Message-ID:In-Reply-To: References:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=jkzFRnRUweg+Dlxs2TW9FhA89ttDAbzAo0ykhEoW1TwutSvtjAtAJmztJJMBRQG+ mj6m+ApxxJZIzkfybug32Q4noD11FXohPX9bkf4fbKVeP1yPcQ+EcwCs2xu45iFrd GkzEWh7Hf+yuF0WSNb+5vxnzsOVg1RvSDQT3nobsqs/3aRijNHaSDVRbXBEygcGRY UCNBJyhF6JdSgWwSDgq+NVOQuBJYB/9bLVGqIt2wh9gvxifKq65lX5v3Rwdgn8O9s t8m2bgSxLCih0+dZ0h788ZpRYajCYqSaQFwgyW7Q9QzGpC6fBhxPn2/SeTk4SnKV8 ZLF8/4lbGOH8OQdyDA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ernst.home ([91.59.228.125]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTRQq-1uZ4AV0Gk8-00XOxd; Thu, 17 Apr 2025 09:45:19 +0200 Date: Thu, 17 Apr 2025 07:45:01 +0000 From: Gary Jennejohn To: Chris Cc: freebsd-current Subject: Re: /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error Message-ID: <20250417094501.2f1600d3@ernst.home> In-Reply-To: <02a330977e072d6953ebbd4f464b44bd@bsdforge.com> References: <02a330977e072d6953ebbd4f464b44bd@bsdforge.com> Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.20.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:VBy+oPAgQTXJMooBo+HbuBfktwwYXfdrdCpN9ITNehwBS50w99F TYnMAQeTt1liaBe6ogK+cj4J3emMeWT6es+B6EUIqivYicC6pH0zf0EENpMbwRLBJkDqHcq 9w3x4/WEPs1C98BLylWqLthJ0r2xSrU5ToWgIbUq5/onAy36qFuI4NrA22SVQRhybJybQEy +bRrH5/s4FjSuV2CPAxqA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:MZGbXXZLtB8=;kOqbmZqnilyWdrPQ4vYFGW/lzzZ 6KeYUdezNnU0jnXKGKDft4ej7qvuk85mWrOu4yC2b6SB3RBqSEDOrxq38Pk5IJ5PsJVshQH1C PKVu1J0O97yxDp9EcuO0nbFlzj6Q8ohyC8SHV6XWCm7/JFGz5qYUnZ5iKHwHY5FEeJdjONvjX o3rv54Qohwj92qoj6lcWRuoafbaTyQwBmnTDOVEM+9BeVwUbqmTPyYjsmWfaZUYGriJUNJgve y6f+TulJiBxschX5JpafB8UFJy+zeUU/7aNHp20ZVNoYp9Ea7gzLPPtRp1YWRsJui8tYbkyko sS43kEVDVf7lMqeWbKCtDhpeWTSZxjA5j9EFUuQq8Oq7K7ZnW+f+VHvwxVgqIFPEPldgs5aly zgCwCXKQl63KCZhECSnTagzwrXGgO1LUffvvmLeT6QyzeJOdfGJE8Xrex/oFqbFG4e2eP8DiB B4/NHXmX8CT0sNYIomSl3RlUGEaWy85bVpMNbzIkqXL9ZGIiN3eXCJvJhdB2ckRJ2Z5b+Eh9Y X+0dsCYi/pxIEr9pJJdpscM52zDINvTmSMk+CVoFz2je9vXQD5JjlGIpeXEiwiHdTNWuRP+ND Z3AOcLjLEnpI0NFpIUNEeAJMUKs/a/NEgzcX6I4/NE0CcQxH0Vsbt1rQZgj+IXXxsJW41njyd tptlZW/ziHsLe3fZuNtIDEzCEIKY/Z4GF0FCz2FmUUWfDKp0JeXoLlzP5KSWcP6W+ulx1THDP ZbNNI2wuXRP6VnQII5/g3T611erfZ2elD1LvdauMmcG4jpfkS4tsOk542HmG48zjz+o0VZYu/ rU4a6N+Kc90ui7+2t7Jl/aZ5gsWgrI8ZfaDcKGenW4l5rQeYKuTR+QYh5m6xHVIc6GVJ67wC4 jy0TmkH894m7nlRo+PKyUvwKiX4vjLu3B0+MfrlaXRhWAGnlgKHpGJbTFm71kgWpL+ExddAMF xUagQIEica39JnVf/KVn1wek2prWdDYqMnSla4BDSRw6xtrI6PMmi3mW6NBJ3VuaNqYWGibDq YsTFbi5YuapdCmSNMH8k3IVrE5AsmnWFvwYbvf+um8Fk95OJ0g1w8JeP1ITpYd10j+GZ/tZpq 4ZsY5BJQ7LYzqZZJ3s5lEuN5T6ZM5RRVRLmMsViEA2P7Ce4DsiiFqtmG+3boXUvrG1u5+UJQm XXvjJk7I3GS0z3yV/YYXGk5z0RVyQ1ih789qQVKBYy6WvOiVP8g3KtSxES2ysTKL7Dxa1CucE 7irHm2xE73h4Uci4yLv7vy8fasiFBV9TRp6IckYaA+9pl/N1AnGhsoMwpuNCaAbVxOpq3QLp1 p4cLLbQ+9Sj4TPlNtGBEVEYt8e3E2C5qPfUB5NVUL5Zl3QovsLgvk8c3CF6qpAYkOUs2uCsn6 ckjfVbdumYEe4skLIiLJj4+qJ/EdPDfODFV+zsKTz9EKqQ+8KmZD5hwPsK43+bvYrg3+pWRYF lXNiBU85r+ByYTb58qGBOs0XUy8c1qYytGLnkUToyonE55xJvYqMp9jfLW1T+mio5oJCmkDTZ zAQXNjzYUtTkZhyVKjUK3TX1ACnyu2klMlkdgdyxgafpIPU9wkoOFZKHaC6LXM2y3cKsR+IJ9 ycBWUsNiCgz3lIW5wkAe14HIgUOV8vddkL2x4x8TYCDdYr+MEEm3e5ky3cuBnpXmAOFS56YdM L3yon5Dz1WTDcePV7A6tzkRfofT3MtVYE+PQwUfIL+H5iXW2Jl3Tq2AZDX+/4juhBJUAZxkMr FbObelD5U9c3a99HcL+8Nvs5VHycExR2C+mlyXVLV7rawEvo9CrrpcBxY+WUXptQ5nMUG65i+ y/ebeOKOHtfJIWPp+q/V62pmIgJucqTT1u2H5bEWH00TEYrlzCnkDaaYQAGmZ3iPxVPlS3TZY qamaPCDbgn82U/myhdPcZG23xceZoL9SuOsjWUUEeKpybZ/zCaAdwQIN5drJCHc+wyTWTR6gx 88dKQmDEuXN4PWeZ1jpMIEs/Sqe+8RJC/2pZEQU8X+OxpIasvUtngbfAipHgp5Py/G6s3KU2Y 1dxifXYsrQ30DriLjMCPxORKBOu3wSD3s+25h+Gj+q+zoSygJ9IRycypiSNH4p9U3UkvkH5Xj Zafut1NieWPNCxS9V4k3GO0qlrkOOoGd+kW/R2nfRJibzcVgZUrJBh+/CcnCMO+DDhpvwpwER 9M+QQIMo0JTg2gqqHGh8uO6K+729/BWznkYsYj3cbSkx6jo2Fw4gLiGHzHIDP9Ryzl7EXZhkK uM0HiCk/lJL4nGZpYjobaEjIcKQdJmtV63gcTGvLi6zM5aaNPiRSlfjbpUnXzsDHlFcOclCKE 4PGAc4buxuzDxtB6MyTWqhJ5Gxs11fydEvrmdAAARPPGoQWXRDFqpEtmckwMl8fH8dCDVE7Fh BdT9LYUO8HL6qbLX9KwpPXQEkNccAoS/TINv4wl3pT8s3MkvPDdDphK9/zdM9FPM2hQyfkXbX rCBELjx8BG2uZc2DhVpHNZD9BQquM8F/djHlitOV/fUSW5dMyxmWneXBEd5qHwrCDbCdOYYEu TlYkEuzgCBsblx4FZb9Kf6BKuO36/T8H/KPI6CszuV2+Yv6B60XuOVQV6Yw2aF9KU6axZVpsY qhVv+OtLVKtvSWW43nmhGT76g4mJvtQQh5iYogKWl63936QzCtE1U3UlSoBo9yh9EXAQevjCX xGEUR0wcap+PXx7J/1bcee4dVcZw/3W+NGITZ40T70VWW9oGHaU0QQANOK3yItxSoGZjQ1sRo iG3LKyi04vMM6bkMOTzanDHecMW0CI3A84x8JTNOHOv0VOUUWOoZQTV/42/vVpwVsirnfSfJA jW8e0Q1OV29DW0siL0XGjBVOyy7x+KvkU7rA6UZFuvuws40BwC8AMmqm//2o6FaWTrO0gBkMD YcKeT19M6mGSbkq9XCbNjcfdDyqqg4Fl6ss720b+DdMbr0xImUi8MlXV5s8TSk+wD58NH0UXO EZqM5Sh2IaSqNjPDsX1+AZSb5c1phONEK6KgpO+T3b1aN37D+S2vxKChim4MDxviETftzYS1f 6f6TKgCsGgdnxp/GdaVjBI/LZJ9GhrlA2qJDya00YFdzLckkmQk6Fuwl/vX+1b/rg== X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Queue-Id: 4ZdVL923Wkz3LbC X-Spamd-Bar: ---- On Wed, 16 Apr 2025 22:06:35 -0700 Chris wrote: > In an attempt to take advantage of all the work > done on iwlwifi recently. I pulled a fresh copy of src > at: >=20 > commit b836c229aa5ac345114f5986b6034ad3ed760da1 (HEAD -> main, freebsd/m= ain,=20 > freebsd/HEAD) > Author: Andrew Gallatin > Date: Tue Apr 15 19:37:06 2025 -0400 >=20 > and proceeded to build world/kernel. The buildkernel stage > stopped at: >=20 > In file included from /usr/src/sys/dev/imcsmb/imcsmb.c:52: > /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error: 'smbus_if.h' fi= le=20 > not found > 52 | #include "smbus_if.h" > 1 error generated. >=20 > I used the same kernconf I used for the kernel I'm using now. > A trip to /usr/src and a search with find(1) confirms the file doesn't > exist. How would I best proceed? >=20 > Thank you for any direction on this. >=20 smbus_if.h is created from /sys/conf/files:dev/smbus/smbus_if.m optional smbus You need device smbus in your kernel config file so that it will be create= d. I don't have smbus in my file and as a result I don't have smbus_if.h on my system. =2D-=20 Gary Jennejohn From nobody Thu Apr 17 09:37:13 2025 X-Original-To: freebsd-current@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 4ZdXqS5lCJz5stFF for ; Thu, 17 Apr 2025 09:37:24 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZdXqS22xjz3xqv; Thu, 17 Apr 2025 09:37:24 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744882644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yxjGfyIhOD3ByzXYprOHMbLrgmM19JgHUnAW0w7REsw=; b=vea15rFPQ+VOAY/40y4kaPNoBZufy3+J2Hl7hb5oYFTsh4ID5WEZMmAtRnBo4fB727ZaxH 0aOpOTXacybaNtZtZvuoQyX+9OdSrY3ji3WCq2kdTIRgMQnM/76yREzl/SWFshMkOig6WH 9Ghp5SfP1k6nheCd8H4iiHD9r7QxvsNrP5DdLn+IqdCiTivM0Ht0YqaO93I6lb59Qr1ORs W2rYgOXC9WygPxU5mxEPnXHlrlIsB2Kvp5xEvWkN3okeN3w3bNsX4nAN+AOfG34WLTm0Ml ehi9ETAukWBRI2P0BFko29DHx2GeMo5CC8+WqJ2XRg3QvkK+8skHl8VGtUJlSA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744882644; a=rsa-sha256; cv=none; b=ltD5MmsUtW0R5AssC6Rmq5ESqpvjrb7zXUaDZ69v+D7cLEpIijBYlgkBNQkj+fNIx6QEVX pxOwMzDeSoKwAXeT+s9F2zEedPZEEqmkk6BUvSBuB9Ss0kLYAkE/IcLP1Gona6Zpgy3/ed k7wteMWMYcXtqeDVt/NM3Y5CKAboAr5pmpbyxt8qqMgyf+dw4VMzwkqpo2SzKt/2bP3rSC 3lJCv0KDyXopXe++FKBnDVmCSqHTUaVtzxE9m6RIFjRi0QJcfhv/CI98P7B9tixBbG0rif HWSx0ingF5RCboj0ZRkzMOVBZMuyNLC4Ofj2kw5crsQDLmiLWWM7o6M7XbRVhg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744882644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yxjGfyIhOD3ByzXYprOHMbLrgmM19JgHUnAW0w7REsw=; b=LYts03QLwIEXZJ9kBZQTcdfBD82R0HjPqcacX7a2RyfPp9GdKn6/GRr60Y/hmyA0dnDDak JwIrSnV7sbGg6L/+4RfqMnUvpT9unncgkugITVV0yw34hGskbZ1+4YjWbL+maYvylpa/Ek //VtB0+3Dsfma1hzKaDt2Ejz3B/8c4Q0l/stLmPjsyFG91bTYB/Gnol6ZdhIAYjMRaZ/HI FV/9r/9zvqeG6InfvEMjXU7XXf+VdxPpZQTMFMS/wHyyiXBtGUJm7QJa3mdX0Gy0hTlgnE DUzajrD5IrWfugaah1MOdkGEo0sVATYI9amD2kNbWS10qV6CbouyibzT9R5JbQ== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZdXqN5Dpqz78Q; Thu, 17 Apr 2025 09:37:20 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_16E5E276-93FC-44AC-B917-C067DA1B54FF" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: "Invoking IPv6 network device address event may sleep with the following non-sleepable locks held"; "sleepable after non-sleepable" Date: Thu, 17 Apr 2025 17:37:13 +0800 In-Reply-To: <0DD42879-97C2-400F-BD94-12A36513B811@yahoo.com> Cc: FreeBSD Current , Mark Johnston To: Mark Millard References: <0DD42879-97C2-400F-BD94-12A36513B811.ref@yahoo.com> <0DD42879-97C2-400F-BD94-12A36513B811@yahoo.com> X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_16E5E276-93FC-44AC-B917-C067DA1B54FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 17, 2025, at 5:17 AM, Mark Millard wrote: >=20 > Context: An aarch64 PkgBase kernel and world boot under Parallels > on macOS (M4 MAX): >=20 > FreeBSD 15.0-CURRENT main-n276258-c5773d366ecc GENERIC arm64 aarch64 = 1500035 >=20 > . . . > vtnet0: link state changed to UP > Invoking IPv6 network device address event may sleep with the = following non-sleepable locks held: > exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r =3D 0 = (0xffffa000c0b3e480) locked @ = /home/pkgbuild/worktrees/main/sys/dev/virtio/network/if_vtnet.c:2202 > stack backtrace: > #0 0xffff000000530f0c at witness_debugger+0x60 > #1 0xffff000000532140 at witness_warn+0x408 > #2 0xffff00000069ede8 at in6_update_ifa+0xa68 > #3 0xffff0000006cbcb0 at in6_ifadd+0x1dc > #4 0xffff0000006c80f8 at nd6_ra_input+0xe38 > #5 0xffff000000699200 at icmp6_input+0x900 > #6 0xffff0000006b2c54 at ip6_input+0xf64 > #7 0xffff000000613a04 at netisr_dispatch_src+0xd8 > #8 0xffff0000005f58d4 at ether_demux+0x174 > #9 0xffff0000005f6f80 at ether_nh_input+0x374 > #10 0xffff000000613a04 at netisr_dispatch_src+0xd8 > #11 0xffff0000005f5d24 at ether_input+0xdc > #12 0xffff000000328ea4 at vtnet_rxq_eof+0x6f4 > #13 0xffff0000003286ec at vtnet_rx_vq_process+0xb0 > #14 0xffff00000031f824 at vtpci_intx_intr+0xe8 > #15 0xffff00000046e0e4 at ithread_loop+0x29c > #16 0xffff00000046a2b0 at fork_exit+0x78 > #17 0xffff0000008897f8 at fork_trampoline+0x18 > lock order reversal: (sleepable after non-sleepable) > 1st 0xffffa000c0b3e480 vtnet0-rx0 (vtnet0-rx0, sleep mutex) @ = /home/pkgbuild/worktrees/main/sys/dev/virtio/network/if_vtnet.c:2202 > 2nd 0xffff000001129640 in6_multi_sx (in6_multi_sx, sx) @ = /home/pkgbuild/worktrees/main/sys/netinet6/in6_mcast.c:1217 > lock order vtnet0-rx0 -> in6_multi_sx attempted at: > #0 0xffff000000530aac at witness_checkorder+0xad0 > #1 0xffff0000004c405c at _sx_xlock+0x70 > #2 0xffff0000006a7a68 at in6_joingroup+0x48 > #3 0xffff00000069f01c at in6_update_ifa+0xc9c > #4 0xffff0000006cbcb0 at in6_ifadd+0x1dc > #5 0xffff0000006c80f8 at nd6_ra_input+0xe38 > #6 0xffff000000699200 at icmp6_input+0x900 > #7 0xffff0000006b2c54 at ip6_input+0xf64 > #8 0xffff000000613a04 at netisr_dispatch_src+0xd8 > #9 0xffff0000005f58d4 at ether_demux+0x174 > #10 0xffff0000005f6f80 at ether_nh_input+0x374 > #11 0xffff000000613a04 at netisr_dispatch_src+0xd8 > #12 0xffff0000005f5d24 at ether_input+0xdc > #13 0xffff000000328ea4 at vtnet_rxq_eof+0x6f4 > #14 0xffff0000003286ec at vtnet_rx_vq_process+0xb0 > #15 0xffff00000031f824 at vtpci_intx_intr+0xe8 > #16 0xffff00000046e0e4 at ithread_loop+0x29c > #17 0xffff00000046a2b0 at fork_exit+0x78 > Starting Network: lo0 vtnet0. > . . . >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 >=20 This is a known ( WIP ) issue. See https://reviews.freebsd.org/D45950 = . Best regards, Zhenlei --Apple-Mail=_16E5E276-93FC-44AC-B917-C067DA1B54FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 17, 2025, at 5:17 AM, Mark Millard <marklmi@yahoo.com> = wrote:

Context: An aarch64 PkgBase kernel and world boot under = Parallels
on macOS (M4 MAX):

FreeBSD 15.0-CURRENT main-n276258-c5773d366ecc GENERIC arm64 = aarch64 1500035

. . .
vtnet0: = link state changed to UP
Invoking IPv6 network device = address event may sleep with the following non-sleepable locks held:
exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r =3D 0 = (0xffffa000c0b3e480) locked @ = /home/pkgbuild/worktrees/main/sys/dev/virtio/network/if_vtnet.c:2202
stack backtrace:
#0 0xffff000000530f0c at = witness_debugger+0x60
#1 0xffff000000532140 at = witness_warn+0x408
#2 0xffff00000069ede8 at = in6_update_ifa+0xa68
#3 0xffff0000006cbcb0 at = in6_ifadd+0x1dc
#4 0xffff0000006c80f8 at = nd6_ra_input+0xe38
#5 0xffff000000699200 at = icmp6_input+0x900
#6 0xffff0000006b2c54 at = ip6_input+0xf64
#7 0xffff000000613a04 at = netisr_dispatch_src+0xd8
#8 0xffff0000005f58d4 at = ether_demux+0x174
#9 0xffff0000005f6f80 at = ether_nh_input+0x374
#10 0xffff000000613a04 at = netisr_dispatch_src+0xd8
#11 0xffff0000005f5d24 at = ether_input+0xdc
#12 0xffff000000328ea4 at = vtnet_rxq_eof+0x6f4
#13 0xffff0000003286ec at = vtnet_rx_vq_process+0xb0
#14 0xffff00000031f824 at = vtpci_intx_intr+0xe8
#15 0xffff00000046e0e4 at = ithread_loop+0x29c
#16 0xffff00000046a2b0 at = fork_exit+0x78
#17 0xffff0000008897f8 at = fork_trampoline+0x18
lock order reversal: (sleepable after = non-sleepable)
1st 0xffffa000c0b3e480 vtnet0-rx0 = (vtnet0-rx0, sleep mutex) @ = /home/pkgbuild/worktrees/main/sys/dev/virtio/network/if_vtnet.c:2202
2nd 0xffff000001129640 in6_multi_sx (in6_multi_sx, sx) @ = /home/pkgbuild/worktrees/main/sys/netinet6/in6_mcast.c:1217
lock order vtnet0-rx0 -> in6_multi_sx attempted at:
#0 0xffff000000530aac at witness_checkorder+0xad0
#1 0xffff0000004c405c at _sx_xlock+0x70
#2 = 0xffff0000006a7a68 at in6_joingroup+0x48
#3 = 0xffff00000069f01c at in6_update_ifa+0xc9c
#4 = 0xffff0000006cbcb0 at in6_ifadd+0x1dc
#5 = 0xffff0000006c80f8 at nd6_ra_input+0xe38
#6 = 0xffff000000699200 at icmp6_input+0x900
#7 = 0xffff0000006b2c54 at ip6_input+0xf64
#8 = 0xffff000000613a04 at netisr_dispatch_src+0xd8
#9 = 0xffff0000005f58d4 at ether_demux+0x174
#10 = 0xffff0000005f6f80 at ether_nh_input+0x374
#11 = 0xffff000000613a04 at netisr_dispatch_src+0xd8
#12 = 0xffff0000005f5d24 at ether_input+0xdc
#13 = 0xffff000000328ea4 at vtnet_rxq_eof+0x6f4
#14 = 0xffff0000003286ec at vtnet_rx_vq_process+0xb0
#15 = 0xffff00000031f824 at vtpci_intx_intr+0xe8
#16 = 0xffff00000046e0e4 at ithread_loop+0x29c
#17 = 0xffff00000046a2b0 at fork_exit+0x78
Starting Network: lo0 = vtnet0.
. . .


=3D=3D=3D
Mark Millard
marklmi at = yahoo.com



This is a known ( WIP ) = issue. See https://reviews.freebsd.org/D45950 .

Best regards,
Zhenlei

= --Apple-Mail=_16E5E276-93FC-44AC-B917-C067DA1B54FF-- From nobody Thu Apr 17 17:39:29 2025 X-Original-To: freebsd-current@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 4ZdlWp1BmPz5sVfF for ; Thu, 17 Apr 2025 17:39:34 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZdlWn3DSqz3kR5; Thu, 17 Apr 2025 17:39:33 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-6e8f43c1fa0so12576746d6.3; Thu, 17 Apr 2025 10:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744911572; x=1745516372; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=qGAIILuPMJoYakZz1MzLKXCGpkQkvRu2PFw6MlWQkAY=; b=Q3S0yNEb9uVJ7GvMXUEog4vd3ybSYtfHOkbtLKh9hFa7pSs8VS6lpLmnUt6UDkFzv4 M+ZsVHWsPRf7DlEkfr+RnMmK8tNnRClHqFTB6wEACxEaWBgTXUQkbha/NfsbmePkzIoG Fp6uQUsNlE391Kkym9CFACTPw/6y9bj17GxTRkm4Wshi/eAzGkmUOzZowlQ3PzN6jsua W3RerZTnWze5wZohVCQbhIS35jBx5RYmVJESI/3Vet4H/vzGexPUmtHyBK0qmseOUrJi hGsG1xOPc/FjeapjLNrGT7iQsddHd5yVaAJ+Q1nOUpeTp6tRI7yAHVBKn/xowo3e4/rs kGfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744911572; x=1745516372; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qGAIILuPMJoYakZz1MzLKXCGpkQkvRu2PFw6MlWQkAY=; b=WphBu2uAy3wV0z6GCx5DEKV6zhaab5+zZQ/H4jVLEig+qJ8g2mxx9LE+879/yEt3SJ yTh1J7Mb6jrJJOsjHSylk9Zzu+3lxSlWDLe3nIs/AzOPdLjjZQHHoq+uW/zIEnbD0WN4 OnKspJns1U5GSoxT9rts9uucB19wRNfnrfk2+qlzUwjHH9n2d3K4nH6xaZAn3Csvz548 6N5lPyYISxekdQwP3L8fo1DGiMu2+wsyvpLYTUxF0O+sSfqnY5s/0KE+DceYMYM00cpX BWKdcPeF2mYIj2FpcpGfR9kdqzl9e+7iOwiI8lgKMoMDKNMhE2+5xWFA/xWZq/4rRDoK wZ7g== X-Forwarded-Encrypted: i=1; AJvYcCXQOzqG8vDf7+WKq/04OJ+V2qXAyA/RMimeVHX/UBbNCQFqAOgEcnKe89UIwJoCbc69U0xSsPqYxWnhO5H5+l4=@freebsd.org X-Gm-Message-State: AOJu0YwiNtG471YvwIE6vy/finTfBUt1R6NdzA3XIMj+RSVk+nuaDdyX B5QXzcCCIWc1zJmwPSKxWWlAuWeemRh1HuVIBv8RnH0hyrAMRX3jjE5Wlg== X-Gm-Gg: ASbGncu1NHUiChVDysFVMMiVs0cTYyRK1zGdKLZCBaFRQaOfwNkfNC9YkQuDyCgXSdA 7XSlHrIYShnJcNAPzZtCZBHPCCjpKB+Ix50Dm09BR+x/txR6KHt93cx736mJYYQrjUJzbAeZPEz yql4L0HYgVt3o+L9oNGj814bdmTtJfab2n0LTqs2BfV8yAzbUTD2QbV1cQY9WJPla7VJTij1DCn 78HM8i99PhIGfixG/dtQvpiR6V+FmbjsGObbBrJGZCofVG+V6HOMlsbat+c5XhAN8cphiK+gCcF vgZMUhqrX5tONZlsWQEAdr5Fiz79qbnPzhlJzk3zVUVJ1DfO8MHoBG0= X-Google-Smtp-Source: AGHT+IHh8tr4poC3CyK2w7mKS3uCtnEvliurGpg8/2eSqZ2NM87V/X1ym8AN1TC8B8zSILCSuIQe7g== X-Received: by 2002:a05:6214:410e:b0:6e8:f17e:e00d with SMTP id 6a1803df08f44-6f2b2f426d1mr100270426d6.14.1744911572100; Thu, 17 Apr 2025 10:39:32 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6f2c2b0f1d9sm1544706d6.43.2025.04.17.10.39.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Apr 2025 10:39:31 -0700 (PDT) Date: Thu, 17 Apr 2025 13:39:29 -0400 From: Mark Johnston To: Zhenlei Huang Cc: Mark Millard , FreeBSD Current Subject: Re: "Invoking IPv6 network device address event may sleep with the following non-sleepable locks held"; "sleepable after non-sleepable" Message-ID: References: <0DD42879-97C2-400F-BD94-12A36513B811.ref@yahoo.com> <0DD42879-97C2-400F-BD94-12A36513B811@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4ZdlWn3DSqz3kR5 X-Spamd-Bar: ---- On Thu, Apr 17, 2025 at 05:37:13PM +0800, Zhenlei Huang wrote: > > > > On Apr 17, 2025, at 5:17 AM, Mark Millard wrote: > > > > Context: An aarch64 PkgBase kernel and world boot under Parallels > > on macOS (M4 MAX): > > > > FreeBSD 15.0-CURRENT main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035 > > > > . . . > > vtnet0: link state changed to UP > > Invoking IPv6 network device address event may sleep with the following non-sleepable locks held: > > exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r = 0 (0xffffa000c0b3e480) locked @ /home/pkgbuild/worktrees/main/sys/dev/virtio/network/if_vtnet.c:2202 > > stack backtrace: > > #0 0xffff000000530f0c at witness_debugger+0x60 > > #1 0xffff000000532140 at witness_warn+0x408 > > #2 0xffff00000069ede8 at in6_update_ifa+0xa68 > > #3 0xffff0000006cbcb0 at in6_ifadd+0x1dc > > #4 0xffff0000006c80f8 at nd6_ra_input+0xe38 > > #5 0xffff000000699200 at icmp6_input+0x900 > > #6 0xffff0000006b2c54 at ip6_input+0xf64 > > #7 0xffff000000613a04 at netisr_dispatch_src+0xd8 > > #8 0xffff0000005f58d4 at ether_demux+0x174 > > #9 0xffff0000005f6f80 at ether_nh_input+0x374 > > #10 0xffff000000613a04 at netisr_dispatch_src+0xd8 > > #11 0xffff0000005f5d24 at ether_input+0xdc > > #12 0xffff000000328ea4 at vtnet_rxq_eof+0x6f4 > > #13 0xffff0000003286ec at vtnet_rx_vq_process+0xb0 > > #14 0xffff00000031f824 at vtpci_intx_intr+0xe8 > > #15 0xffff00000046e0e4 at ithread_loop+0x29c > > #16 0xffff00000046a2b0 at fork_exit+0x78 > > #17 0xffff0000008897f8 at fork_trampoline+0x18 > > lock order reversal: (sleepable after non-sleepable) > > 1st 0xffffa000c0b3e480 vtnet0-rx0 (vtnet0-rx0, sleep mutex) @ /home/pkgbuild/worktrees/main/sys/dev/virtio/network/if_vtnet.c:2202 > > 2nd 0xffff000001129640 in6_multi_sx (in6_multi_sx, sx) @ /home/pkgbuild/worktrees/main/sys/netinet6/in6_mcast.c:1217 > > lock order vtnet0-rx0 -> in6_multi_sx attempted at: > > #0 0xffff000000530aac at witness_checkorder+0xad0 > > #1 0xffff0000004c405c at _sx_xlock+0x70 > > #2 0xffff0000006a7a68 at in6_joingroup+0x48 > > #3 0xffff00000069f01c at in6_update_ifa+0xc9c > > #4 0xffff0000006cbcb0 at in6_ifadd+0x1dc > > #5 0xffff0000006c80f8 at nd6_ra_input+0xe38 > > #6 0xffff000000699200 at icmp6_input+0x900 > > #7 0xffff0000006b2c54 at ip6_input+0xf64 > > #8 0xffff000000613a04 at netisr_dispatch_src+0xd8 > > #9 0xffff0000005f58d4 at ether_demux+0x174 > > #10 0xffff0000005f6f80 at ether_nh_input+0x374 > > #11 0xffff000000613a04 at netisr_dispatch_src+0xd8 > > #12 0xffff0000005f5d24 at ether_input+0xdc > > #13 0xffff000000328ea4 at vtnet_rxq_eof+0x6f4 > > #14 0xffff0000003286ec at vtnet_rx_vq_process+0xb0 > > #15 0xffff00000031f824 at vtpci_intx_intr+0xe8 > > #16 0xffff00000046e0e4 at ithread_loop+0x29c > > #17 0xffff00000046a2b0 at fork_exit+0x78 > > Starting Network: lo0 vtnet0. > > . . . > > > > > > === > > Mark Millard > > marklmi at yahoo.com > > > > > > > This is a known ( WIP ) issue. See https://reviews.freebsd.org/D45950 . Yes, I got somewhat stuck on figuring out how to deal with the rx taskqueue there. I'm pretty sure it can be removed, but would need to think about it more and do a fair bit of testing. From nobody Thu Apr 17 18:41:44 2025 X-Original-To: freebsd-current@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 4Zdmvh3cvBz5sb4n for ; Thu, 17 Apr 2025 18:41:52 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zdmvh0Sj5z3DL8 for ; Thu, 17 Apr 2025 18:41:51 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53HIfiD3085604; Thu, 17 Apr 2025 11:41:51 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1744915311; x=1744915911; r=y; bh=CJp65pykcqRn1F3wJilz/plHo1UWV/sqoZZDXuUmsq0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=CS77ZY3vH+0NbLzIrjk4OE05mYJBComwoSlNde4s0fsZb8/q7tf+dETmNZu2QC8ho 9IG2mRDJymCjYKXl/DQ4tpMkDQNcc1PfhGqEkJMJdYOgvDhrneOWeIGEwOnt/IcM0f 0HQlgjZ1duAgDPHuWaKgT1SgI4kOAsMTdz6tS81o9lg7tXkEHo6JquLk/0ZWMEO+kq z/unET4RsEZiT/dQvd1DX1ViIq9XSz+D6qkJZdatT1pc4nOUmgJiEH6n00E5J9qklE GU7lUW0bnHjlrSYX+wZd4wFbfSSYDuPh8CCXh/fkIoyWlc90tyQb4hyDQHWWf4tPLe DCKDkvlSvkBSQ== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Thu, 17 Apr 2025 11:41:44 -0700 From: Chris To: Mark Millard Cc: FreeBSD Current Subject: Re: /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error In-Reply-To: References: <8E088E3D-2617-4B0A-BAE0-E9199DDA4F1B.ref@yahoo.com> <8E088E3D-2617-4B0A-BAE0-E9199DDA4F1B@yahoo.com> User-Agent: UDNSMS/17.0 Message-ID: <690c2c6a7843225c67636cc0f912c36e@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_18152ca20a75fcbc9d7276b735d1827d" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4Zdmvh0Sj5z3DL8 X-Spamd-Bar: ---- --=_18152ca20a75fcbc9d7276b735d1827d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2025-04-17 00:19, Mark Millard wrote: > [Note: Your Email handling rejects my Emails, probably > because of Yahoo being involved.] Looks like sonic317-22.consmr.mail.gq1.yahoo.com Sorry. Looks like you were the victim of using the same IP as a recent attacker. Filters against yahoo are short lived. I've cleared it for you. :) > > On Apr 16, 2025, at 23:46, Chris wrote: > >> On 2025-04-16 22:40, Mark Millard wrote: >>> Chris wrote on >>> Date: Thu, 17 Apr 2025 05:06:35 UTC : >>>> In an attempt to take advantage of all the work >>>> done on iwlwifi recently. I pulled a fresh copy of src >>>> at: >>>> commit b836c229aa5ac345114f5986b6034ad3ed760da1 (HEAD -> main, >>>> freebsd/main, >>>> freebsd/HEAD) >>>> Author: Andrew Gallatin >>>> Date: Tue Apr 15 19:37:06 2025 -0400 >>>> and proceeded to build world/kernel. The buildkernel stage >>>> stopped at: >>>> In file included from /usr/src/sys/dev/imcsmb/imcsmb.c:52: >>>> /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error: 'smbus_if.h' >>>> file >>>> not found >>>> 52 | #include "smbus_if.h" >>>> 1 error generated. >>>> I used the same kernconf I used for the kernel I'm using now. >>>> A trip to /usr/src and a search with find(1) confirms the file doesn't >>>> exist. How would I best proceed? >>> I've no explicit use of such but when I looked on >>> a system here, I found a imcsmb/smbus_if.h inside >>> a build tree from a buildkernel : >>> # find -s / -name smbus_if.h -print | grep imcsmb >>> /usr/obj/BUILDs/main-ZNV4-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/i2c/controllers/imcsmb/smbus_if.h >> Performing the same here returns nothing. In an effort to ensure adequate >> space prior to the build. I clobbered /usr/obj. :( > > Do you have any paths that involve: > Thanks for all your work here, Mark. I ran a grep -RF against /usr/src to get some clues. I discovered much the same as you. It appears the missing file is created during the build process. But apparently not, in my case.. I clobbered /usr/obj after my last reply in hopes it was an incidental read/write hiccup. But the build failed. While the missing file was reported as the cause. The error was slightly different. At this point I'm inclined to simply grab a fresh copy of src and try this again. I'll report my findings in a couple/three hours when it should then be complete. Thank you again, for all your time and efforts here! --Chris > sys/modules/i2c/controllers/imcsmb/ > > ? Do you have the likes of ( you likely > have /usr/src/, not /usr/main-src/ ): > > # more /usr/main-src/sys/modules/i2c/controllers/imcsmb/Makefile > .PATH: ${SRCTOP}/sys/dev/imcsmb > KMOD = imcsmb > SRCS = device_if.h bus_if.h pci_if.h smbus_if.h \ > imcsmb.c imcsmb_pci.c imcsmb_reg.h imcsmb_var.h > > .include > > # grep -rl imcsmb /usr/main-src/sys/ | more > /usr/main-src/sys/modules/i2c/controllers/imcsmb/Makefile > /usr/main-src/sys/modules/i2c/controllers/Makefile > /usr/main-src/sys/x86/conf/NOTES > /usr/main-src/sys/dev/imcsmb/imcsmb_reg.h > /usr/main-src/sys/dev/imcsmb/imcsmb.c > /usr/main-src/sys/dev/imcsmb/imcsmb_var.h > /usr/main-src/sys/dev/imcsmb/imcsmb_pci.c > /usr/main-src/sys/conf/files.x86 > > # grep imcsmb /usr/main-src/sys/x86/conf/NOTES > /usr/main-src/sys/conf/files.x86 > /usr/main-src/sys/x86/conf/NOTES:# imcsmb integrated Memory Controller (iMC) > SMBus > controller > /usr/main-src/sys/x86/conf/NOTES:device imcsmb > /usr/main-src/sys/conf/files.x86:dev/imcsmb/imcsmb.c optional imcsmb > /usr/main-src/sys/conf/files.x86:dev/imcsmb/imcsmb_pci.c optional imcsmb pci > >>> (Some of the naming and upper-level path structure is >>> unusual. See what is normal in your context.) >>> So it appears that sys/modules/i2c/controllers/imcsmb/smbus_if.h >>> needs to have been built first and that a -I PATH or such needs >>> to be used to find the file. >> Really appreciate the clues here, Mark. I'll keep investigating. The >> build worked last time with this kernconf. So there must be a way. > > === > Mark Millard > marklmi at yahoo.com -- sent from hardware written from and running on FreeBSD --=_18152ca20a75fcbc9d7276b735d1827d Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_18152ca20a75fcbc9d7276b735d1827d-- From nobody Thu Apr 17 18:48:24 2025 X-Original-To: freebsd-current@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 4Zdn3W1j86z5sbZj for ; Thu, 17 Apr 2025 18:48:39 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zdn3V4qWJz3Hk5 for ; Thu, 17 Apr 2025 18:48:38 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53HImPZ1012821; Thu, 17 Apr 2025 11:48:37 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1744915717; x=1744916317; r=y; bh=HSRotPn9h90ip3tIMFoXcQ2UwyimOk5AOWvJ09D6p8w=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=upWFKP7ugwYALpsrF8237zx9NbfXUpqQVecYLic9ZJUkYElRQibi3AGZd8Q9AJmB6 b3SBjPslRDnoVi07BH/IhCOUwulZsfo2yLQLpXTY7aPVuTPZVmRuaBUbOZUVWbXKiq ZzB0rCMr/0UOTqbTZOgRVyl6KEfjjKZ1u7PXK4EGBTDFZeY6IpaE0A2za+wIj/ioPW Ms/Q1AM6PdfyM28OZMK5bE7YdYouUxDbFNkkCwEHKr7RUTI6PPnNd9ct18GYy2AC8f om53fxbgStzoiE8LAFt14LD42OuEodM03QyzHFfNY0vshm8SXqd6TuUHEwO/KrMJor l2z46EeIXyIWg== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Thu, 17 Apr 2025 11:48:24 -0700 From: Chris To: garyj@gmx.de Cc: freebsd-current Subject: Re: /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error In-Reply-To: <20250417094501.2f1600d3@ernst.home> References: <02a330977e072d6953ebbd4f464b44bd@bsdforge.com> <20250417094501.2f1600d3@ernst.home> User-Agent: UDNSMS/17.0 Message-ID: <3478cc9d34dda674488081ac9e37e036@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_09336843c6528fc84205439ee06b0eca" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4Zdn3V4qWJz3Hk5 X-Spamd-Bar: ---- --=_09336843c6528fc84205439ee06b0eca Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2025-04-17 00:45, Gary Jennejohn wrote: > On Wed, 16 Apr 2025 22:06:35 -0700 > Chris wrote: > >> In an attempt to take advantage of all the work >> done on iwlwifi recently. I pulled a fresh copy of src >> at: >> >> commit b836c229aa5ac345114f5986b6034ad3ed760da1 (HEAD -> main, >> freebsd/main, >> freebsd/HEAD) >> Author: Andrew Gallatin >> Date: Tue Apr 15 19:37:06 2025 -0400 >> >> and proceeded to build world/kernel. The buildkernel stage >> stopped at: >> >> In file included from /usr/src/sys/dev/imcsmb/imcsmb.c:52: >> /usr/src/sys/dev/imcsmb/imcsmb_var.h:52:10: fatal error: 'smbus_if.h' file >> not found >> 52 | #include "smbus_if.h" >> 1 error generated. >> >> I used the same kernconf I used for the kernel I'm using now. >> A trip to /usr/src and a search with find(1) confirms the file doesn't >> exist. How would I best proceed? >> >> Thank you for any direction on this. >> > > smbus_if.h is created from > /sys/conf/files:dev/smbus/smbus_if.m optional smbus Great clue here, Gary. Thanks! > > You need device smbus in your kernel config file so that it will be created. Right. As I mentioned. I'm using the same kernconf I used to build the kernel I'm currently using. dmesg(8) reports: smbios0: at iomem 0x40084000-0x4008401e smbios0: Version: 3.3, BCD Revision: 3.3 ichsmb0: port 0xefa0-0xefbf mem 0x6001144000-0x60011440ff at device 31.4 on pci0 smbus0: on ichsmb0 So it appears that my system uses it. Now, if I can only get my OS to provide it. ;) Thanks for that great clue and all your time here, Gary! --Chris > > I don't have smbus in my file and as a result I don't have smbus_if.h on > my system. -- sent from hardware written from and running on FreeBSD --=_09336843c6528fc84205439ee06b0eca Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_09336843c6528fc84205439ee06b0eca-- From nobody Tue Apr 15 17:39:36 2025 X-Original-To: freebsd-current@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 4Zdt0g2T5Yz5stJX for ; Thu, 17 Apr 2025 22:31:31 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zdt0g1B37z3q7Y; Thu, 17 Apr 2025 22:31:31 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744929091; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xVFFzLtP8rG4JaFC0CUaULZl+4dDayk/2zY1JygSS24=; b=qxwVx/FKLgZRj0riFqEAqI8zvAxfiMH7fNEyoxw4Kg5o7S5J17PR5fNc4fGSlbLSAZsOHB WQTvMTDp2CcrsPOD2MAHHLHCQ2UTivSzpcX4mdRJ346oXVNdjIek5bi+R/YGj+zZXlFvIQ KkDZskdrhVY3lkCbbK2d32cTP7gjxQ99TPxX1jyz/UEvdMVbfwohD3NZc1nWhQr5RDLpNj NnGCQoIcNW2jwYkAfy+nZroSti3PRmIrpMMEpcO2zQoQLzEPiAIX8Oib/08KmA1q7Pc8gG 2uc83I1c3vS561I+gWOhaBUUIZPXtbo0z7Yb4Og3OInD5Nan6LX2FblrrZTVew== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744929091; a=rsa-sha256; cv=none; b=QPBgg0C+m2Vfo3+GeDHVw1+CPtQJp9ImHP/fteRmZj74sfPhbnK9FEHzpuNWdmpec9Y09g kVUtMUivenIzhBVjays512wiNpulA9cOqVmV1wawobr809ON7PGK5PAteJqKT8iuzZIo78 2tlkuqRyUvZGatsADhSzelkfCY/rTuc9aupWGi89AyzAxGxrfRMUTz/WlSvRQg89lqahk3 ijHIOfxyZCesx0Su+r30s8rLwHONx5flLnUzYOfRmWFpcB/uG4Q8b9NKoYLTSqbqSHOyid oa2AWuPwqbb+6uOAY8mJ16bQvZZBVQMs/etvAPtSLq3MjNiQ9lJQfqDPqbCOTw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744929091; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xVFFzLtP8rG4JaFC0CUaULZl+4dDayk/2zY1JygSS24=; b=MWccS0zpAgRsi4zA6FOrfJKUykdD/ZtMlEGIZBJyQVvO4K30On4J0wyg0Skl8fNWHRmeOo ZN/DZRyHstYIvfkfVK4UnjdGHX8APv6YmosROimwm7Zrt3jts3GYWzV7egPbPNkkpf0PGb HfGqV+nr8kObsH5NYLy3Q1MK+DUNj3LYFO6PVIFMJ2lWODYNZQ33H8MQTFfQhMTZDGeD2+ lkep2915RZwl5POfd+1Db+rztvWLen+/VryDET5ZyrM9zqnBV9SUWyOFCpns+E+y2HH7RG Sk5Ld+jrK80oC4eWCylNsDNvJPwHuN9ZljYXrDYBPuBQmpNX5hcK4lkO3i9Abg== Received: from ltc.des.dev (88-177-82-251.subs.proxad.net [88.177.82.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zdt0g0D6bzPvr; Thu, 17 Apr 2025 22:31:31 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 68AC2EE096; Tue, 15 Apr 2025 19:39:36 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alastair Hogge Cc: freebsd-current@freebsd.org Subject: Re: etcupdate failed to build tree with read-only /usr/src In-Reply-To: (Alastair Hogge's message of "Sun, 13 Apr 2025 02:51:17 +0000") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 15 Apr 2025 19:39:36 +0200 Message-ID: <86plhdb9yf.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alastair Hogge writes: > After the build processes complete [...] > > $ doas su - > # cd /usr/src > # etcupdate -p > # env MAKEOBJDIRPREFIX=3D/tmp/fafnir make installkernel > # env MAKEOBJDIRPREFIX=3D/tmp/fafnir make installworld > # etcupdate > > Here etcupdate exits with, "Failed to build new tree." Since you just completed buildworld, you should be using `etcupdate -B` here. It will save you time and should work around the read-only issue. (I really wish -B were the default, and we had -b instead for the less-common opposite case.) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Fri Apr 18 02:40:24 2025 X-Original-To: freebsd-current@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 4ZdzWv27SGz5tC88 for ; Fri, 18 Apr 2025 02:40:27 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.riseup.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZdzWt51JMz440d; Fri, 18 Apr 2025 02:40:26 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; none Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx1.riseup.net (Postfix) with ESMTPS id 4ZdzWr4V82zDqNk; Fri, 18 Apr 2025 02:40:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1744944024; bh=X53HfC3IUZbuVUGuLluPnrXxAt046R0Eq1YVI8VJbBk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JQkMBDbygOhhVS4bCg3vQa2mjIYuv0VVbH2wNtkT165UcTbMhCzgnpzpSZCKhHZqA z7KNtgoAX7YLk5GQADh8jKiwd65PogBA37TTuQTk6lnThc9xiUXm2e4K/T3XLUUqyg zSopffh7v46pCTpbw4ThOr8kQ6gkHduBwJ8Y+niY= X-Riseup-User-ID: 55CD6F7BE9E65BC0B12B302273976DF0AFC9E4CDA13A3EFC8765F4DEDAB032D2 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4ZdzWr2mqhzFrQ9; Fri, 18 Apr 2025 02:40:24 +0000 (UTC) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Fri, 18 Apr 2025 02:40:24 +0000 From: Alastair Hogge To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: freebsd-current@freebsd.org Subject: Re: etcupdate failed to build tree with read-only /usr/src In-Reply-To: <86plhdb9yf.fsf@ltc.des.dev> References: <86plhdb9yf.fsf@ltc.des.dev> Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US] X-Rspamd-Queue-Id: 4ZdzWt51JMz440d X-Spamd-Bar: ---- On 2025-04-16 01:39, Dag-Erling Smørgrav wrote: > Alastair Hogge writes: >> After the build processes complete [...] >> >> $ doas su - >> # cd /usr/src >> # etcupdate -p >> # env MAKEOBJDIRPREFIX=/tmp/fafnir make installkernel >> # env MAKEOBJDIRPREFIX=/tmp/fafnir make installworld >> # etcupdate >> >> Here etcupdate exits with, "Failed to build new tree." > > Since you just completed buildworld, you should be using `etcupdate -B` > here. It will save you time and should work around the read-only issue. Hmm I did try $(etcupdate -B), and I recall it also failing, so I updated another host, and used -B with etcupdate, and it failed for another reason: >>> update command: rerun= tarball= preworld= >>> update command: rerun= tarball= preworld= >>> Building tree at /var/db/etcupdate/etcupdate-WXYm41T with make -DNO_FILEMON make[1]: warning: /usr/src/: Read-only file system. -------------------------------------------------------------- >>> Making hierarchy -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 distrib-dirs make[2]: warning: /usr/src/: Read-only file system. cd /usr/src/etc; MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=znver2 CC="cc -target x86_64-unknown-freebsd15.0 --sysroot=/net/fafnir/obj/usr/src/amd64.amd64/tmp -B/net/fafnir/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="c++ -target x86_64-unknown-freebsd15.0 --sysroot=/net/fafnir/obj/usr/src/amd64.amd64/tmp -B/net/fafnir/obj/usr/src/amd64.amd64/tmp/usr/bin" CPP="cpp -target x86_64-unknown-freebsd15.0 --sysroot=/net/fafnir/obj/usr/src/amd64.amd64/tmp -B/net/fafnir/obj/usr/src/amd64.amd64/tmp/usr/bin" AS="as" AR="ar" ELFCTL="elfctl" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" STRIPBIN="strip" PATH=/net/fafnir/obj/usr/src/amd64.amd64/tmp/bin:/net/fafnir/obj/usr/src/amd64.amd64/tmp/usr/sbin:/net/fafnir/obj/usr/src/amd64.am d64/tmp/usr/bin:/net/fafnir/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/net/fafnir/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/net/fafnir/obj/usr/src/amd64.amd64/tmp/legacy/bin:/net/fafnir/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/s bin:/usr/bin make INSTALL="install -N /usr/src/etc" MTREE_CMD="mtree -N /usr/src/etc" METALOG= distrib-dirs for file in /usr/include/c++/v1/__string /usr/include/c++/v1/__tuple /usr/libexec/kgdb; do if [ -f /var/db/etcupdate/etcupdate-WXYm41T/${file} ]; then rm -f /var/db/etcupdate/etcupdate-WXYm41T/${file}; fi; done mtree -N /usr/src/etc -deU -i -f /usr/src/etc/mtree/BSD.root.dist -p /var/db/etcupdate/etcupdate-WXYm41T/ ld-elf.so.1: Shared object "libmd.so.6" not found, required by "mtree" *** Error code 1 Stop. make[3]: stopped in /usr/src/etc *** Error code 1 -- To good health, Alastair From nobody Fri Apr 18 06:24:15 2025 X-Original-To: freebsd-current@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 4Zf4V93dkzz5tVhy for ; Fri, 18 Apr 2025 06:24:17 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zf4V906fyz3DxW; Fri, 18 Apr 2025 06:24:17 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744957457; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lQ98MJJhXSJkudkBz4K2WabZ7Gj8kEcea42AizKOmAU=; b=pYp3JwvR00sCGucZO6y8Onlm/znyffQ2qbrIzr96LrvN3P4GuNU8y7csK2bdvQlAu7qwBZ Ef+QrCbxOEw5zbeikoW78Opt0okkIEydfKeOtIrSKMPyBEc+C0zoErvyQDxU2C+mIMuwtn 7Px0CUOW22bIWW2TeuOUeIKh6d58dbbCOvzMEu7YZWxgWQ/Dqn9rJlNZ4a29bA3HBzg+iR 03Ar1qXXABK4srr4mpO3m3oonGptWuIAMuV4NpFRteVmqCaRbsga2TsrRJJ7ohjT7/Ik71 K35AIg0I0460tPdMuJi91akKMi9ihjcF5mPnERKVl86T7F7ZWUspB1HCSJnrQw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744957457; a=rsa-sha256; cv=none; b=T23I025rMmBdLET1aPzWMavLHzRxjEMYcuO86qc7ZVNFTGspbmoaxTqiM3suZoFlw7Bocz TD+Kh4DqY+bEapVGRWh29q2cHyx2D1TfVpmJngyYXKmSeU9FCg/TzVoRN1TJQx3OEM1LGa YgnItYCnBpFKL027EpaAm2+qmKHwTRip8KxPapNfBfqJ4PKr1LwV/2KOANSrot4u+R6p0f FGbFl1/LwxGxh6JEM6XfZKBVOTBeBQfC5nmuKTxz4zLv76dPYL8guH0nJ6NOHySpHB0+LP 6UzFxFbQlhUD4nqlgMxJew1SMvdKnBjjGK6IIDjRjoEyySPmaDFJSu9Nyp+JRA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744957457; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lQ98MJJhXSJkudkBz4K2WabZ7Gj8kEcea42AizKOmAU=; b=ikN2U6PIF6Wh73rbuxLBsOsQF69D+wBhRon/Q+ildyhpfk5ssI6d0w4t42hyV0nYr74Cvb m0y6fSPZ0ea7ARWQDCctkj6wzBOjMI6FEsHsVGOZCADpvnhsKiGtxWgutZw9Az2B1ojTtZ KjbfAkOo0SCy+uJ8QRckBrElNe+R+jOiZ9KAYlXXLEsqsBaHUkXAN2dazhQqyHnwzDoLgK nmzJXuWr8pHSNvCkGyllIFKreK2/IEzFj8qNxk9i+D4/TIGuuidgrziHEMHweY27aHcgfT M5HR55kInEoIpsqiBQZGNYQyVuDzIpMwUUkJv8jKOBn4+PASAIFPmgBVd33gYQ== Received: from ltc.des.dev (88-177-82-251.subs.proxad.net [88.177.82.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zf4V85ssLzr3h; Fri, 18 Apr 2025 06:24:16 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 5788EEDF71; Fri, 18 Apr 2025 08:24:15 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alastair Hogge Cc: freebsd-current@freebsd.org Subject: Re: etcupdate failed to build tree with read-only /usr/src In-Reply-To: (Alastair Hogge's message of "Fri, 18 Apr 2025 02:40:24 +0000") References: <86plhdb9yf.fsf@ltc.des.dev> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 18 Apr 2025 08:24:15 +0200 Message-ID: <86r01q6l80.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alastair Hogge writes: > Hmm I did try $(etcupdate -B), and I recall it also failing, so I > updated another host, and used -B with etcupdate, and it failed for > another reason: > [...] > ld-elf.so.1: Shared object "libmd.so.6" not found, required by "mtree" > *** Error code 1 This is _after_ installworld, right? `etcupdate -p`, then installworld, then `etcupdate -B`? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Fri Apr 18 14:49:51 2025 X-Original-To: current@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 4ZfHjb0qn7z5svQd; Fri, 18 Apr 2025 14:49:55 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZfHjb05Phz3c5w; Fri, 18 Apr 2025 14:49:55 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744987795; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4uMNGgWlQ2zzjQL26B363vT+zwW0MkbD3meqq5egtGs=; b=kfhAPysg8eSdZ4waSyxHAHWMlHRt21qSnq2eIgZRn+HexodDHc98WnuLPLt9uq9NoRbXdJ kOWfDBo34E7dprIlOvXQKRN0OSlKyqz0wwA70WRGDCcbyAId1xU1SOzLOX3rwnxZpMyTPe yMRjwJc0nZyUxjTZu/43BAEo7XkFBeVe6YDAkTZcpFVQJLk/fKLNhiSzL4q4962JfrEnow QXZj8y9InGCcaQWeeDPje0FeZ1dWXFSTBFqEQ/g/HBHXb3WqOeFOLJ/emPTJwRZYXtxbx4 W7ipLuT1D9TNZKl0XsiLYre/0guRl2MILRfv0USLkyTSGwxkOM+2J6tl2QTKyQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744987795; a=rsa-sha256; cv=none; b=EnBZTC/MpzJgW+3ZpEuIpRzirb2TlDrD3LS0IXusjUQK/4cyVEAge2zjHaVudQTIemJ08C 1X86nJW9ueE0rOScJyMu29joR6wNsg4QGR5RLLt4ZIYEXuhZigwFYYupDowYWyIeJYpOLa jZ95xpZQfuLiLr9fM8M21HOzOfvZ6qkr4cT2W2XEfaguDe4aiHuXWDWP5ULjjiVrXJs29e nrAQBMPVqBulDSioLbP5fqJaqoGonPHA+S6gtJD0xJgMg1YvwhtZdeOC5Y9VW9JJYQzixk x5BAhO6Kh/WCCdw6EWfccMnxfqPnNUABAifDcbILOrvGtcOhESYqnWjqVs49oQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744987795; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4uMNGgWlQ2zzjQL26B363vT+zwW0MkbD3meqq5egtGs=; b=Cju49K3fhiQf/CvQiOl87jgcqQjgvoOSfxDgT80OaAqHHoAFQEeHizRzkNFGz2dq/6GdTt 3C/tDTC5otVxR03RKPo/AgozpQ8njBmeFkj5rsRVt0BuoBzzKHt3ZYPhUr4RlIu+qOsfE1 jgLY0MAnN1K/+R3YllQGe+iL/gB8ZnIlB8sHP7MG1tSeDlrk847vu/c+8ff+zMk+g1Wy7H kS+ML5nLFfYZF18OAO1TxZA0F6fn814YV2VHCy2BN0+prZIdERmZ900ahscwjSICR8MZ7h EbNcIGLlGIwE7TCKJ1DBNHSTPvG/YmHa/N30xTFuUEUe5OU8a2CHtU4qhKXdLg== Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZfHjZ4qPyz125G; Fri, 18 Apr 2025 14:49:54 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id 6FCC3A64806; Fri, 18 Apr 2025 14:49:52 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C6D172D029E0; Fri, 18 Apr 2025 14:49:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id nrzJoUNmyjdD; Fri, 18 Apr 2025 14:49:51 +0000 (UTC) Received: from strong-rtwn0.sbone.de (strong-rtwn0.sbone.de [IPv6:fde9:577b:c1a9:4902:3e64:cfff:fe55:bc80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 944D42D029D8; Fri, 18 Apr 2025 14:49:51 +0000 (UTC) Date: Fri, 18 Apr 2025 14:49:51 +0000 (UTC) From: "Bjoern A. Zeeb" To: FreeBSD wireless mailing list cc: current@freebsd.org, stable@freebsd.org, desktop@freebsd.org Subject: Re: HEADS UP: iwlwifi firmware removed from main (stable/14 to follow), run fwget before updating In-Reply-To: <5p424pns-6p6s-1952-r39o-q20s240o7opn@SerrOFQ.bet> Message-ID: <66301543-0q8q-6prr-o804-3419ops00sn3@SerrOFQ.bet> References: <02s8on48-41s3-1s5n-4nqn-0s88434946q3@SerrOFQ.bet> <5p424pns-6p6s-1952-r39o-q20s240o7opn@SerrOFQ.bet> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed On Thu, 10 Apr 2025, Bjoern A. Zeeb wrote: Hi, and the firmware is now also gone from stable/14 (which at the same time got a few bug fixes for LinuxKPI malloc and LinuxKPI 802.11). In case you run into any issues updating from a supported 14.x or 15 (younger than a year old [3]) please follow-up, ideally on the wireless mailing list. Lots of health, Bjoern [3] https://lists.freebsd.org/archives/freebsd-wireless/2025-April/003199.html > On Wed, 19 Mar 2025, Bjoern A. Zeeb wrote: > > Hi, > > before updating your system please run fwget(8) or build > wifi-firmware-iwlwifi-kmod (or the appropriate flavor) from ports if you > are using iwlwifi(4) or iwx(4). > > You can do it any time as the extra firmware files will do no harm until > your next reboot at least. > > As announced almost a month ago firmware just got removed from the src > repository main branch [1]. stable/14 will follow in a few days. > > If you are using iwlwifi(4) you may get automatically upgraded to > HT and VHT support by the tunables the firmware installs along (if you > haven't done yourself in the last weeks already). > I wrote a summary for testing [2] the other day and the freebsd wireless > list is generally a good place to follow and the right place to follow > up. > The email may also help in case you face problems though I am fervently > working on solving open problems currently, so by the time you update > they may already be gone.. (famous last words). > > [1] > https://cgit.FreeBSD.org/src/commit/?id=558d638896239f9cd25b9d825ecfce62ec54681e > [2] > https://lists.freebsd.org/archives/freebsd-wireless/2025-April/003131.html > > Lots of joy, > Bjoern > >> I pushed an update to the iwlwifi firmware port today[1] and with the last >> release of FreeBSD 13 being out the door, 14.1-Release EoL end of this >> month passed and the packages for the updated port appearing I'll >> >> !!! >> remove iwlwifi firmware from src.git for main and stable/14 >> some time early April. >> !!! >> >> >> * What you need to do? >> >> Please run fwget(8) to install the right firmware package for your chipset >> if you have not already and then pkg upgrades will provide updates as >> needed. >> You can do this today already as that won't change the status quo compared >> to what is in the tree. >> >> >> * Why is this happening? >> >> iwlwifi following rtw88 and rtw89 after a request from core to not add >> more binary blob wireless firmware into src.git (accumulated firmware >> for a set of modern wireless drivers at that time would have been >> slightly over 100MB if I remember correctly with the amount increasing). >> >> As a result firmware was put into ports, broken down into flavors, added >> to fwget(8) to automatically install it, updated the port to no longer >> install kernel modules but firmware files on 14.2-R and later, enhanced >> the install media to contain firmware so wireless-only laptops could have >> connectivity with these drivers, and enhanced the installer to have a step >> to run fwget and install firmware into the new installation. All of this >> shipped in 14.2-R already. >> Thanks to everyone who helped along these steps to make it all happen. >> >> >> * What's your bonus? >> >> If you have't already tried yourself, the updated port will also turn on >> HT and VHT by default for iwlwifi chipsets 22000, ax210, and bz (that's >> AX200 and newer) on both main and stable/14. >> Reports so far have been encouraging enough from some people who've been >> testing during the last weeks (the rough edges being sorted step but >> step now). For more information about how to test, about older chipsets, >> or other drivers see the wireless mailing list archive[2] of this year >> and the FreeBSD Foundation Laptop Project on github [3] for links to the >> postings. >> >> Please follow up as appropriate on the wireless list. >> >> >> Lots of health and joy, >> Bjoern >> >> >> [1] >> https://cgit.freebsd.org/ports/commit/?id=ef3fa2a325a592baa6573782a72cf0d833589ffa >> [2] https://lists.freebsd.org/archives/freebsd-wireless/ >> [3] https://github.com/FreeBSDFoundation/proj-laptop/ >> >> > > -- Bjoern A. Zeeb r15:7 From nobody Fri Apr 18 22:03:15 2025 X-Original-To: current@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 4ZfTKf4tPVz5tRgY for ; Fri, 18 Apr 2025 22:03:18 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZfTKf4JFVz43mD for ; Fri, 18 Apr 2025 22:03:18 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745013798; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:autocrypt:autocrypt; bh=gjdwKWFQoy0H5zqvkAaN2DOSKrdZ7g2qkPlNsHhYiB8=; b=I3wMuAZjFQvISFjrm5zay25GIE7jDY54OcOz5IaSXg/wg7YpCIef+vhPDdWQVt8/iott7A dhQihPCppMtDsog9Ey1DA7UMzOCEpm2/vcPTrZGJBqAA2T6+X9B/PEflliUzXyGkhYU04H 29/JxhqONSMjaviUyCB4TEfhMK6kfhUH3LnWwwvwa6EpodXgS2o8zH+sYJVE5yoJ9tfJVX 17CF2gRmy5ClvEjB+r+NPMm8nJZOY7aA/BoqQd/C7HKsSBBPj0xfXmuQcZEmI1c2zhUikj Hw4sUqdDjzOzglWueA4krTJwTvtfWsT37/cyy89MB7ABnjrkUyx9zodPQhf1Iw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745013798; a=rsa-sha256; cv=none; b=TNkSt1pcxQQENQMMbh+2nKrOxfzwdFLQcEbZ2Dtm9E9TXumvmBH0hwQn8MdPhpAy3SpvPu Ut32GtGSyUjIZT/jRUuPYFdfhzNJclMoiEqzZB6eijOWPARUdwcvA0DFUl9MelD37bWsUH YfGVRKwU5+5FJfLdQAZg9lhnM20h4ZtO9xzGoAImlHl3f1ABE8Fpvl8YvnuKOeOzucaduM GRIwWdVWR/3UYILKQSv6AmqS3nJEJrwcHTMJH3RtTCw8OFzUYqRavKbe+mUVrORIWFR1m+ YNNPD7m/MOsesbgSFW3h4i4EXFOovrYc5zGiWWLcBuFUGsWd/4S1qdFc9ex5hA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745013798; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:autocrypt:autocrypt; bh=gjdwKWFQoy0H5zqvkAaN2DOSKrdZ7g2qkPlNsHhYiB8=; b=WiKDNmP208bmNqNUtwkqMbhQel8u1CeEjYdDy3Ohu1YkG0erwcLgalDdm6/j0siK0CWjtk t82F3jnuH+8abMxvaRAEj5SraBzvvGl2AdWzgzD1I1naPeXTHEo9ItmH0dmXbDShVZSYgz xffHQGNe5cLUjOgfICIO461+mRaQoU3uRCYlwsz9fXfHIxQH9erJMs+FQimIiELEEV/dz1 J2IssqRYcox6OmmUEUkUC6XWEFoffiU2Ap7uKtMP8N5ccs+SDVeOw70Lf1E45ePs22zpJf jEwcTMMu6BPxRTRht20GYrnQXUx5yGJ84IqNMqIWafzw3JxPXCNACuu2o7bwLg== Received: from [192.168.0.88] (unknown [93.188.39.137]) (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) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZfTKf2GMcz19tQ for ; Fri, 18 Apr 2025 22:03:18 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> Date: Sat, 19 Apr 2025 01:03:15 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FreeBSD Current From: Andriy Gapon Subject: RTLD_DEEPBIND question Autocrypt: addr=avg@FreeBSD.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I am trying to understand if RTLD_DEEPBIND should help in the following scenario or if I misunderstand its purpose. There is a program that has a parser based on lex/yacc, so there is function yyparse in the code and global text symbol yyparse in the binary. The program can load shared objects (plugins) using dlopen. One of the plugins is linked with a shared library... actually with libdtrace.so. The library has its own parser (for DTrace language) and it also has yyparse global text symbol. There is a problem that when the program dlopen-s the plugin and calls its code the yyparse calls in libdtrace get resolved to the yyparse function in the program itself, not in libdtrace. This is, of course, not unexpected according to how dlopen works. However, I expected that if I add RTLD_DEEPBIND to the dlopen call that loads the plugin then libdtrace's yyparse calls would get resolved to the libdtrace yyparse because they all are in the same dependency subtree. But adding RTLD_DEEPBIND does not seem to help, libdtrace yyparse calls are still resolved to the main binary's yyparse. I should also note that the main binary does not have any dependency on libdtrace. It comes into picture only through the plugin. P.S. I think that the issue could be resolved by building libdtrace differently, so that its yyparse is resolved at link time and is not treated as a global symbol. And I think that we should probably do it. However, I am still curious if RTLD_DEEPBIND should have helped here. Thank you. -- Andriy Gapon From nobody Fri Apr 18 23:41:19 2025 X-Original-To: current@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 4ZfWW24svvz5tYdy for ; Fri, 18 Apr 2025 23:41:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4ZfWW14LL7z3xkC; Fri, 18 Apr 2025 23:41:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 53INfKi0084943; Sat, 19 Apr 2025 02:41:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 53INfKi0084943 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 53INfKht084942; Sat, 19 Apr 2025 02:41:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Apr 2025 02:41:19 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current Subject: Re: RTLD_DEEPBIND question Message-ID: References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4ZfWW14LL7z3xkC X-Spamd-Bar: ---- On Sat, Apr 19, 2025 at 01:03:15AM +0300, Andriy Gapon wrote: > > I am trying to understand if RTLD_DEEPBIND should help in the following > scenario or if I misunderstand its purpose. > > There is a program that has a parser based on lex/yacc, so there is function > yyparse in the code and global text symbol yyparse in the binary. > > The program can load shared objects (plugins) using dlopen. > > One of the plugins is linked with a shared library... actually with libdtrace.so. > The library has its own parser (for DTrace language) and it also has yyparse > global text symbol. > > There is a problem that when the program dlopen-s the plugin and calls its > code the yyparse calls in libdtrace get resolved to the yyparse function in > the program itself, not in libdtrace. > This is, of course, not unexpected according to how dlopen works. > > However, I expected that if I add RTLD_DEEPBIND to the dlopen call that > loads the plugin then libdtrace's yyparse calls would get resolved to the > libdtrace yyparse because they all are in the same dependency subtree. > > But adding RTLD_DEEPBIND does not seem to help, libdtrace yyparse calls are > still resolved to the main binary's yyparse. Could it be that the module is linked to the main binary? RTLD_DEEPBIND works by first iterating over all (recursive) DT_NEEEDED object for the object where the symbol is resolved, then by looking at the global list of loaded objects. Non-deepbind resolution is performed by looking at the global list. You can see it in the rtld.c:symlook_default(). Also it might be useful to set LD_DEBUG=1 and read the debugging output from rtld. > > I should also note that the main binary does not have any dependency on > libdtrace. It comes into picture only through the plugin. > > P.S. > I think that the issue could be resolved by building libdtrace differently, > so that its yyparse is resolved at link time and is not treated as a global > symbol. > And I think that we should probably do it. > However, I am still curious if RTLD_DEEPBIND should have helped here. > > Thank you. > -- > Andriy Gapon > From nobody Sat Apr 19 01:19:52 2025 X-Original-To: freebsd-current@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 4ZfYhV5xkwz5sSjK for ; Sat, 19 Apr 2025 01:19:54 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx0.riseup.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZfYhV3317z3p44; Sat, 19 Apr 2025 01:19:54 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; none Received: from fews01-sea.riseup.net (fews01-sea-pn.riseup.net [10.0.1.109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4ZfYhS4X8jz9sZv; Sat, 19 Apr 2025 01:19:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1745025592; bh=bCzpNqcBF7M/IAUSwZnmR32Ari4+SuPQKnNi78f5vP0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZuiVeCZbL6+TApPoOKjnYqfTDvztWMFZP4Mu8/Hc/RppEMewyvZ2qHwD0xOGBAXsy ZgKqLgsD00nkubBD6SlCWWVXQmpMpbgVQUZVZhIvWZcdtuX//uFY02QAXJT6RwUrMm 2LrCBkYpFuIpD24rRz5jarHApF3BycvldQGRXu0M= X-Riseup-User-ID: 3BB3E93A0CAA428CEB2350D614902558B6F41F13D748B678351CD70B51EDF52C Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4ZfYhS33c1zJn9R; Sat, 19 Apr 2025 01:19:52 +0000 (UTC) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Sat, 19 Apr 2025 01:19:52 +0000 From: Alastair Hogge To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: freebsd-current@freebsd.org Subject: Re: etcupdate failed to build tree with read-only /usr/src In-Reply-To: <86r01q6l80.fsf@ltc.des.dev> References: <86plhdb9yf.fsf@ltc.des.dev> <86r01q6l80.fsf@ltc.des.dev> Message-ID: <57f4bff1402023ce197c27f540e9f138@riseup.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US] X-Rspamd-Queue-Id: 4ZfYhV3317z3p44 X-Spamd-Bar: ---- On 2025-04-18 14:24, Dag-Erling Smørgrav wrote: > Alastair Hogge writes: >> Hmm I did try $(etcupdate -B), and I recall it also failing, so I >> updated another host, and used -B with etcupdate, and it failed for >> another reason: >> [...] >> ld-elf.so.1: Shared object "libmd.so.6" not found, required by "mtree" >> *** Error code 1 > > This is _after_ installworld, right? `etcupdate -p`, then installworld, > then `etcupdate -B`? I would have thought so. I no longer have the terminal history from that attempt, and have spent all of yesterday chasing a bug that broke SSH based PAM login at the physical terminal, broke $(su -), and broke $(doas su -). I will try and find some time again for $(etcupdate -B). From nobody Sat Apr 19 03:22:21 2025 X-Original-To: current@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 4ZfcPs3N2Tz5sdFF for ; Sat, 19 Apr 2025 03:22:25 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx0.riseup.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZfcPq42kwz3cMp for ; Sat, 19 Apr 2025 03:22:23 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=ghqSB8M+; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.6 as permitted sender) smtp.mailfrom=agh@riseup.net Received: from fews01-sea.riseup.net (fews01-sea-pn.riseup.net [10.0.1.109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4ZfcPn5Xt0z9sZv for ; Sat, 19 Apr 2025 03:22:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1745032941; bh=mJqyrkSKNRQmQnGyW21NvFQt/soHxxAFqGxHIpvlAJs=; h=Date:From:To:Subject:From; b=ghqSB8M+iFQzxBl/5UYswamy8+YXpnU1bG96m9fpVuJTJ8iRerDdn6Rh5Pwta6GPw d64UCbPUYGWvQzslVEe3Jl773I7TVcW00eBp0BLNMGNpkGKaiVeeoEFsID+ZebvtpJ nWYYYDLAhqtTnhBhXpkczyFGhUweynv7LQnD2t/U= X-Riseup-User-ID: 49000A3B1B72107CB49A90DD8FA81866ADC669FFB1BBA147523FE90B758749F8 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4ZfcPn49cJzJqhf for ; Sat, 19 Apr 2025 03:22:21 +0000 (UTC) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Sat, 19 Apr 2025 03:22:21 +0000 From: Alastair Hogge To: current@freebsd.org Subject: 15-CURRENT /usr/lib/pam_ssh.so.6: /usr/lib/libprivatessh.so.5: Undefined symbol "Fssh_sshsk_sign" Message-ID: <640b7a090b6a9cf3c2ffbaebc36ed2a8@riseup.net> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.68 / 15.00]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.71)[-0.707]; NEURAL_SPAM_MEDIUM(0.52)[0.525]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[198.252.153.6:from]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; R_SPF_ALLOW(-0.20)[+a:mx0.riseup.net]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.6:from]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RECEIVED_HELO_LOCALHOST(0.00)[]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[riseup.net:+]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[] X-Rspamd-Queue-Id: 4ZfcPq42kwz3cMp X-Spamd-Bar: --- Hello, After attempting to update from 168d873ae41fd8bd40555322a79c9f215cb4cb9c[1] (2025-04-17 19:08:02 +0000), to 7121e9414f294d116caeadd07ebd969136d3a631[2] (2025-04-18 00:30:11 +0000), I noticed that $(su -), $(doas su -), x11/slim, and physical login were not working, when pam_ssh is configured for login. I was still able to use $(doas some_cmd), so was able to git bisect. The following commit[3] is claimed to the the first offending commit from the git-bisect process: The branch main has been updated by jlduran: URL: https://cgit.FreeBSD.org/src/commit/?id=65d8491719bbc88ed45637d2381931c2d29cfe87 commit 65d8491719bbc88ed45637d2381931c2d29cfe87 Author: Jose Luis Duran AuthorDate: 2025-04-17 19:08:02 +0000 Commit: Jose Luis Duran CommitDate: 2025-04-17 19:12:39 +0000 secure: Adapt Makefile to ssh-sk-client everywhere Upstream commit 7b47b40b1 ("adapt Makefile to ssh-sk-client everywhere") adapted the Makefiles to ssh-sk-client. Do the same here. Reviewed by: emaste Approved by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D49795 --- I am not sure if security/opendoas needed to be rebuilt, I did not bother, because $(su -) threw the same error: su: pam_start: System error With the commit[3] of interest, dmesg produces the following, regarding slim: [12.609735] Apr 18 03:45:50 direwolf slim[42177]: in try_dlopen(): /usr/lib/pam_ssh.so.6: /usr/lib/libprivatessh.so.5: Undefined symbol "Fssh_sshsk_sign" [12.609775] Apr 18 03:45:50 direwolf slim[42177]: in openpam_load_module(): no pam_ssh.so found I noticed three interesting changes in the commit[3]: diff --git a/secure/lib/libssh/Makefile b/secure/lib/libssh/Makefile index f4c60c02c9eb..39083d007675 100644 --- a/secure/lib/libssh/Makefile +++ b/secure/lib/libssh/Makefile @@ -38,7 +38,6 @@ SRCS= ${LIBOPENSSH_SRCS} \ kexsntrup761x25519.c kexmlkem768x25519.c sntrup761.c kexgen.c \ sftp-realpath.c platform-pledge.c platform-tracing.c platform-misc.c \ sshbuf-io.c -SRCS+= ssh-sk-client.c I restored "SRCS+= ssh-sk-client.c" above. And I have restored all opendoas operations, slim, and physical access. diff --git a/secure/ssh.mk b/secure/ssh.mk index 641343ac993a..84d9a7f57032 100644 --- a/secure/ssh.mk +++ b/secure/ssh.mk @@ -5,6 +5,7 @@ SSHDIR= ${SRCTOP}/crypto/openssh SFTP_CLIENT_SRCS=sftp-common.c sftp-client.c sftp-glob.c +SKSRCS= ssh-sk-client.c CFLAGS+= -I${SSHDIR} -include ssh_namespace.h Above, ssh-sk-client.c is present in ssh.mk, should that enable Fssh_sshsk_sign symbol visibility? diff --git a/secure/usr.bin/ssh-keygen/Makefile b/secure/usr.bin/ssh-keygen/Makefile index 89e61e68ee55..c9205e71d219 100644 --- a/secure/usr.bin/ssh-keygen/Makefile +++ b/secure/usr.bin/ssh-keygen/Makefile @@ -2,8 +2,7 @@ .include "${SRCTOP}/secure/ssh.mk" PROG= ssh-keygen -# XXX ssh-sk-client.c in libssh maybe? -SRCS= ssh-keygen.c sshsig.c ssh-sk-client.c +SRCS= ssh-keygen.c sshsig.c $(SKSRCS) PACKAGE= ssh LIBADD= crypto ssh The XXX comment above seem to indicate there might be a problem with removing ssh-sk-client.c from libssh. 1: https://cgit.freebsd.org./src/commit/?id=168d873ae41fd8bd40555322a79c9f215cb4cb9c 2: https://cgit.freebsd.org./src/commit/?id=7121e9414f294d116caeadd07ebd969136d3a631 3: https://cgit.freebsd.org./src/commit/?id=65d8491719bbc88ed45637d2381931c2d29cfe87 -- To good health, Alastair From nobody Sat Apr 19 09:25:57 2025 X-Original-To: current@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 4ZfmTP2Dz1z5t6Hd for ; Sat, 19 Apr 2025 09:26:01 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZfmTP1YbQz3CNK; Sat, 19 Apr 2025 09:26:01 +0000 (UTC) (envelope-from avg@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745054761; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=zzStLrSGFlU+UvDe7xbE77Cql659X1cKbKdSC8wQ2e8=; b=FiSTDsTTofPaJ38NMYa37HdEMLjOxmlIZpwcm7FbNC2lMghQdDKZWdaT8G5h99qhA5D7xh J5jBDrm9WPNqddshbuqY/SJePioSqpQGHXURQHicZwlrbBU6WoDPHGh8B7v02I9xI0R2I0 Khz+OgfJi9S8ZmzKhrTP2s4aIV/oQfUGU1R6ZqvtLdADCTX38Qde/nAmDomLGW5VA3rKzF gI8kXnQeAFd1aP+1jz+diu7jvprnkVv9ogo9jVCkFyRhCeeRVxpPmW22SHInnawwxfoUux jybYDAtvxUfigxCHHVB9iC5ypUOLQKTyrF1HwkJVWSa92H7FQJ4Y5eUIWcM4RQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745054761; a=rsa-sha256; cv=none; b=B8ILVrnwXNdB88S/ecLhgsldE9ftSBZV65ZEsUB3ACksUj82M0Lv7tTTIO4LC2mODlTbYb MYfM1oogJM/o/0LDLvlHA7sKghnpwFNi0kMRm4YRy4Z2a7sufdEye1hwTZTucOpFsWxmNV kosZzkij6UNEIDLqpDw/8njXD9CdWr4w5QDdEwhLGXm/24SRYIqP4LMcyoZ7Be8+yfqkXT Vyk8fUhkbYuK7PSNhF1ayzFmYgPfF35ubFst+xBH1Q/9XonBajR5+QxiiUy1Z816LX3MnX /Eno8z0cren5KRZLx+jiFCVw1Dc4qFGkIsgL2Sr6qxStq6K5pYTF/9K52QPYhQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745054761; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=zzStLrSGFlU+UvDe7xbE77Cql659X1cKbKdSC8wQ2e8=; b=igryK7RzI+ODkl30IV/GIosG7EhtGAtGj7t9Xm+ZPm7WoqEz+fa+aMH5JS7dO+YXIryFiI n2FfmTSiQmO/cwIx9J+QIL7xvJZl3uwpXHgUin9IRG3BXNXG0adyIJJbuWsdlyHdhYxHiD EILzWldBe6ff2eGmWFi/iz5aWq6tHlrxrDjLOhR9/VsroQbVUtCTsNJgHg5KN3C0S65LXe AdGGdes7PUdKPn6VoXbgRwFBpNO2naSDpDf/NohwTQGF6ScM4OJO2Pcc2X44NtwO/ShS1i qfFseUu34wee8dsrMiixo6tScXQFIPcgDYDNe8VylWSEHts0Ymv18LfK8SAzIw== Received: from [192.168.0.88] (unknown [93.188.39.137]) (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) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZfmTN5LmLzBR0; Sat, 19 Apr 2025 09:26:00 +0000 (UTC) (envelope-from avg@freebsd.org) Message-ID: <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> Date: Sat, 19 Apr 2025 12:25:57 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Andriy Gapon Subject: Re: RTLD_DEEPBIND question To: Konstantin Belousov Cc: FreeBSD Current References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> Content-Language: en-US Autocrypt: addr=avg@freebsd.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 19/04/2025 02:41, Konstantin Belousov wrote: > Could it be that the module is linked to the main binary? It does not appear to be so. The binary: $ ldd /usr/local/bin/mdb /usr/local/bin/mdb: libncursesw.so.9 => /lib/libncursesw.so.9 (0xbf191c93000) libtinfow.so.9 => /lib/libtinfow.so.9 (0xbf190b45000) libkvm.so.7 => /lib/libkvm.so.7 (0xbf192a74000) libproc.so.5 => /usr/lib/libproc.so.5 (0xbf1930f4000) librtld_db.so.2 => /usr/lib/librtld_db.so.2 (0xbf19382d000) libctf.so.2 => /lib/libctf.so.2 (0xbf19466c000) libumem.so.2 => /lib/libumem.so.2 (0xbf194b0a000) libelf.so.2 => /lib/libelf.so.2 (0xbf194eb6000) libutil.so.9 => /lib/libutil.so.9 (0xbf19550c000) libz.so.6 => /lib/libz.so.6 (0xbf195875000) libc.so.7 => /lib/libc.so.7 (0xbf1961fb000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0xbf197493000) libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0xbf197753000) libspl.so.2 => /lib/libspl.so.2 (0xbf197f77000) libsys.so.7 => /lib/libsys.so.7 (0xbf198bc6000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xbf199475000) [vdso] (0xbf1902db000) The module: $ ldd /usr/local/lib/mdb/kvm/amd64/dtrace.so /usr/local/lib/mdb/kvm/amd64/dtrace.so: libdtrace.so.2 => /lib/libdtrace.so.2 (0x24d1702c8000) libm.so.5 => /lib/libm.so.5 (0x24d1711c3000) libc.so.7 => /lib/libc.so.7 (0x24d16cfbb000) libctf.so.2 => /lib/libctf.so.2 (0x24d16eee6000) libelf.so.2 => /lib/libelf.so.2 (0x24d16c13e000) libproc.so.5 => /usr/lib/libproc.so.5 (0x24d172085000) librtld_db.so.2 => /usr/lib/librtld_db.so.2 (0x24d173d46000) libxo.so.0 => /lib/libxo.so.0 (0x24d172b1d000) libthr.so.3 => /lib/libthr.so.3 (0x24d17411c000) libspl.so.2 => /lib/libspl.so.2 (0x24d174e8d000) libz.so.6 => /lib/libz.so.6 (0x24d173a38000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x24d17635a000) libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x24d175fb8000) libutil.so.9 => /lib/libutil.so.9 (0x24d176864000) libsys.so.7 => /lib/libsys.so.7 (0x24d16df97000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x24d17567f000) libkvm.so.7 => /lib/libkvm.so.7 (0x24d177768000) > RTLD_DEEPBIND works by first iterating over all (recursive) DT_NEEEDED > object for the object where the symbol is resolved, then by looking at > the global list of loaded objects. > Non-deepbind resolution is performed by looking at the global list. > > You can see it in the rtld.c:symlook_default(). > > Also it might be useful to set LD_DEBUG=1 and read the debugging output > from rtld. Thank you for reminding me about LD_DEBUG.I can provide the full output I got with it, but here are some interesting bits. BTW, I tried both RTLD_NOW and RTLD_LAZY, just in case. There was no difference in behavior. This output is when using RTLD_LAZY. dlopen_object name "/usr/local/lib/mdb/kvm/amd64/dtrace.so" fd -1 refobj "/usr/local/bin/mdb" lo_flags 0x82 mode 0x1 lm_find("/usr/local/bin/mdb", "/usr/local/lib/mdb/kvm/amd64/dtrace.so") lml_find(0x2fe0e1004198, "/usr/local/lib/mdb/kvm/amd64/dtrace.so") loading "/usr/local/lib/mdb/kvm/amd64/dtrace.so" /usr/local/lib/mdb/kvm/amd64/dtrace.so valid_hash_sysv 1 valid_hash_gnu 1 dynsymcount 75 0x1b24f41bf000 .. 0x1b24f41cdfff: /usr/local/lib/mdb/kvm/amd64/dtrace.so lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "libdtrace.so.2") lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") lml_find(0x2fe0e1004198, "libdtrace.so.2") Searching for "libdtrace.so.2" search_library_pathfds('libdtrace.so.2', '(null)', fdp) lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "/lib") lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") Trying "/lib/libdtrace.so.2" Opened "/lib/libdtrace.so.2", fd 51 loading "/lib/libdtrace.so.2" /lib/libdtrace.so.2 valid_hash_sysv 1 valid_hash_gnu 1 dynsymcount 810 0x1b24efbcc000 .. 0x1b24efc7afff: /lib/libdtrace.so.2 lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "libm.so.5") lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "/lib") lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") lm_find("/lib/libdtrace.so.2", "libxo.so.0") lmp_find("/lib/libdtrace.so.2") lm_find("/lib/libdtrace.so.2", "/lib") lmp_find("/lib/libdtrace.so.2") lm_find("/lib/libdtrace.so.2", "libthr.so.3") lmp_find("/lib/libdtrace.so.2") lm_find("/lib/libdtrace.so.2", "/lib") lmp_find("/lib/libdtrace.so.2") relocating "/usr/local/lib/mdb/kvm/amd64/dtrace.so" relocating "/lib/libdtrace.so.2" calling init function for /lib/libdtrace.so.2 at 0x1b24efc689cc calling init function for /lib/libdtrace.so.2 at 0x1b24efc179a0 calling init function for /lib/libdtrace.so.2 at 0x1b24efc420d0 "getenv" in "libdtrace.so.2" ==> 0x1b24edfea3f0 in "libc.so.7" "rd_init" in "libdtrace.so.2" ==> 0x1b24e9dd07d0 in "librtld_db.so.2" calling init function for /usr/local/lib/mdb/kvm/amd64/dtrace.so at 0x1b24f41cacac calling init function for /usr/local/lib/mdb/kvm/amd64/dtrace.so at 0x1b24f41c49e0So far so good, I think.The module got loaded, libdtrace got loaded as its dependency and then some dependencies Then I executed a command that made a call into dtrace.so module. "mdb_getopts" in "dtrace.so" ==> 0x1b1cc46b6760 in "mdb" "mdb_readvar" in "dtrace.so" ==> 0x1b1cc46db470 in "mdb" "mdb_vread" in "dtrace.so" ==> 0x1b1cc46db040 in "mdb" "memset" in "dtrace.so" ==> 0x1b24edfde8f0 in "libc.so.7" "dtrace_vopen" in "dtrace.so" ==> 0x1b24efc43320 in "libdtrace.so.2" "elf_version" in "libdtrace.so.2" ==> 0x1b24eafbefe0 in "libelf.so.2" "calloc" in "libdtrace.so.2" ==> 0x1b24edffd0a0 in "libc.so.7" "dt_proc_init" in "libdtrace.so.2" ==> 0x1b24efc5be40 in "libdtrace.so.2" "dt_zalloc" in "libdtrace.so.2" ==> 0x1b24efc61df0 in "libdtrace.so.2" "pthread_mutex_init" in "libdtrace.so.2" ==> 0x1b24edf165d0 in "libc.so.7" "pthread_cond_init" in "libdtrace.so.2" ==> 0x1b24edf163d0 in "libc.so.7" "strdup" in "libdtrace.so.2" ==> 0x1b1cc46ed5a0 in "mdb" "malloc" in "libdtrace.so.2" ==> 0x1b24edffc370 in "libc.so.7" (lots of output skipped) "dt_idstack_push" in "libdtrace.so.2" ==> 0x1b24efc360c0 in "libdtrace.so.2" "dt_irlist_create" in "libdtrace.so.2" ==> 0x1b24efc1b240 in "libdtrace.so.2" "yyinit" in "libdtrace.so.2" ==> 0x1b24efc3b030 in "libdtrace.so.2" "strlen" in "libdtrace.so.2" ==> 0x1b24edfdfc30 in "libc.so.7" "yybegin" in "libdtrace.so.2" ==> 0x1b24efc39b00 in "libdtrace.so.2" "setjmp" in "libdtrace.so.2" ==> 0x1b24edf3ede0 in "libc.so.7" "yyparse" in "libdtrace.so.2" ==> 0x1b1cc46fe300 in "mdb" The last line is what causes the trouble. It's interesting that yyinit and yybegin were resolved correctly... ah, but there are no such symbols in the main binary. Additional info: $ nm -D /usr/local/bin/mdb | grep yyparse 00000000000b6300 T yyparse $ nm -D /usr/local/lib/mdb/kvm/amd64/dtrace.so| grep yyparse $ $ nm -D /lib/libdtrace.so.2 | grep yyparse 0000000000066460 T yyparse $ nm -D /usr/local/bin/mdb | grep yybegin $ -- Andriy Gapon From nobody Sat Apr 19 09:39:27 2025 X-Original-To: current@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 4Zfmmx609Jz5t66p for ; Sat, 19 Apr 2025 09:39:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zfmmx3CfZz3KcM; Sat, 19 Apr 2025 09:39:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745055569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=mCOzrtx2tYm2qta4wXEss21i5megjwLSYq6KbWlaZ/E=; b=wlzI78GXL/J/7G5rnLcvhzgZHTqdGWN97403n97I0mmxvpW0pTCvG3OmVZ0zkEJkFWVGXq s5EmCp5U6RqUu/EgmJRIvU8ZpNVQdlY2d6pZRbF0YRqTdBcCUKllX5hbH57kobkP8FQ81r GZL2hsBnBIrDI1t2jki9c8auPQDG8XJ6FIMYuC368IV+G0njUgjp4zlVoZs8uu8GAJX1mD TH6o3ik06rqOXXOe5MVGpLiJem1gvIAOzk3IRP3zHFaVLWWYLRIzNOmO1WNpY+ybHlDHQh ArDFri5Ibo9jJaNwk0I4PKVCugJqtmQ8fQEQESKKTCe6yGreBGSPBwf5IhRmqA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745055569; a=rsa-sha256; cv=none; b=f6YyHKEgbDazypoY3xhAtNAbEX5kLSRD0tIC6oTVnSfraHl1uDoXIWAQEmrkwGjiDBm57n mo9VIJY8QeCc8X8rQG9iMD1nEfOQGhmiUEFg0UztkT3echy29iheVmfMDbvEVc+mjJ2Map ET4peELf5rTG1EVuK0p90HMXvHHqIuSNJubuBfFLmJpx269moLW31dp0i6fQQpGgPUFKhF 4P/azgy0+qv1wDBGX24vDtlKb9VIbXAWpY7UXXIsbQeCDpkBP6+2yVDPwxCKpBbRiDMOa2 5W+DL1RHzAIHOmSizhldkhE+jpqKomcwXgr0RnL6Meo+8lZ9icy4sK53eGmuoA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745055569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=mCOzrtx2tYm2qta4wXEss21i5megjwLSYq6KbWlaZ/E=; b=tAAIOlP4ZL6amy7A2RzbkK+uKx/vqyW7uRdN3mgkKvHGHo6ek3rtKuz9dKZHqFtk81rEvV 2uEeY299GhG9nqjYRsevweZNvwWZl6WGlFX42YcEnrVDpHLqRsV4BznS0R5h5dtQld2V8a SgeQZSB6aVdtpfh1okXqJYo9g56B74aCX+Hts2sNEuz8aCodBr69e3YngdzYD1PmeUnmel VnDOoicgq0lNMMioSsKUmgpCryKsyKxi62ePEzlmKiAbIVD/rCwbkVhFwlVRGzKRQodeC0 hbKrTfc3rzauUNj+2G7AjLPpzyNMh9AKKdvBkXBQqdJWvIFfI4PQqLb3EhAqug== Received: from [192.168.0.88] (unknown [93.188.39.137]) (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) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zfmmw6sDGzByP; Sat, 19 Apr 2025 09:39:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Sat, 19 Apr 2025 12:39:27 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RTLD_DEEPBIND question From: Andriy Gapon To: Konstantin Belousov Cc: FreeBSD Current References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> Content-Language: en-US Autocrypt: addr=avg@FreeBSD.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 In-Reply-To: <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 19/04/2025 12:25, Andriy Gapon wrote: > On 19/04/2025 02:41, Konstantin Belousov wrote: >> Could it be that the module is linked to the main binary? > > It does not appear to be so. > The binary: > $ ldd /usr/local/bin/mdb > /usr/local/bin/mdb: >         libncursesw.so.9 => /lib/libncursesw.so.9 (0xbf191c93000) >         libtinfow.so.9 => /lib/libtinfow.so.9 (0xbf190b45000) >         libkvm.so.7 => /lib/libkvm.so.7 (0xbf192a74000) >         libproc.so.5 => /usr/lib/libproc.so.5 (0xbf1930f4000) >         librtld_db.so.2 => /usr/lib/librtld_db.so.2 (0xbf19382d000) >         libctf.so.2 => /lib/libctf.so.2 (0xbf19466c000) >         libumem.so.2 => /lib/libumem.so.2 (0xbf194b0a000) >         libelf.so.2 => /lib/libelf.so.2 (0xbf194eb6000) >         libutil.so.9 => /lib/libutil.so.9 (0xbf19550c000) >         libz.so.6 => /lib/libz.so.6 (0xbf195875000) >         libc.so.7 => /lib/libc.so.7 (0xbf1961fb000) >         libcxxrt.so.1 => /lib/libcxxrt.so.1 (0xbf197493000) >         libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0xbf197753000) >         libspl.so.2 => /lib/libspl.so.2 (0xbf197f77000) >         libsys.so.7 => /lib/libsys.so.7 (0xbf198bc6000) >         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xbf199475000) >         [vdso] (0xbf1902db000) > > The module: > $ ldd /usr/local/lib/mdb/kvm/amd64/dtrace.so > /usr/local/lib/mdb/kvm/amd64/dtrace.so: >         libdtrace.so.2 => /lib/libdtrace.so.2 (0x24d1702c8000) >         libm.so.5 => /lib/libm.so.5 (0x24d1711c3000) >         libc.so.7 => /lib/libc.so.7 (0x24d16cfbb000) >         libctf.so.2 => /lib/libctf.so.2 (0x24d16eee6000) >         libelf.so.2 => /lib/libelf.so.2 (0x24d16c13e000) >         libproc.so.5 => /usr/lib/libproc.so.5 (0x24d172085000) >         librtld_db.so.2 => /usr/lib/librtld_db.so.2 (0x24d173d46000) >         libxo.so.0 => /lib/libxo.so.0 (0x24d172b1d000) >         libthr.so.3 => /lib/libthr.so.3 (0x24d17411c000) >         libspl.so.2 => /lib/libspl.so.2 (0x24d174e8d000) >         libz.so.6 => /lib/libz.so.6 (0x24d173a38000) >         libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x24d17635a000) >         libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x24d175fb8000) >         libutil.so.9 => /lib/libutil.so.9 (0x24d176864000) >         libsys.so.7 => /lib/libsys.so.7 (0x24d16df97000) >         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x24d17567f000) >         libkvm.so.7 => /lib/libkvm.so.7 (0x24d177768000) > >> RTLD_DEEPBIND works by first iterating over all (recursive) DT_NEEEDED >> object for the object where the symbol is resolved, then by looking at >> the global list of loaded objects. >> Non-deepbind resolution is performed by looking at the global list. >> >> You can see it in the rtld.c:symlook_default(). From a quick look at the code, should we try to resolve the symbol in refobj itself when it's marked with deepbind? >> Also it might be useful to set LD_DEBUG=1 and read the debugging output >> from rtld. > Thank you for reminding me about LD_DEBUG.I can provide the full output I got > with it, but here are some interesting bits. > BTW, I tried both RTLD_NOW and RTLD_LAZY, just in case. > There was no difference in behavior. > This output is when using RTLD_LAZY. > > dlopen_object name "/usr/local/lib/mdb/kvm/amd64/dtrace.so" fd -1 refobj "/usr/ > local/bin/mdb" lo_flags 0x82 mode 0x1 > > lm_find("/usr/local/bin/mdb", "/usr/local/lib/mdb/kvm/amd64/dtrace.so") > lml_find(0x2fe0e1004198, "/usr/local/lib/mdb/kvm/amd64/dtrace.so") > loading "/usr/local/lib/mdb/kvm/amd64/dtrace.so" > /usr/local/lib/mdb/kvm/amd64/dtrace.so valid_hash_sysv 1 valid_hash_gnu 1 > dynsymcount 75 >   0x1b24f41bf000 .. 0x1b24f41cdfff: /usr/local/lib/mdb/kvm/amd64/dtrace.so > lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "libdtrace.so.2") > lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") > lml_find(0x2fe0e1004198, "libdtrace.so.2") >  Searching for "libdtrace.so.2" > search_library_pathfds('libdtrace.so.2', '(null)', fdp) > lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "/lib") > lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") >   Trying "/lib/libdtrace.so.2" >   Opened "/lib/libdtrace.so.2", fd 51 > loading "/lib/libdtrace.so.2" > /lib/libdtrace.so.2 valid_hash_sysv 1 valid_hash_gnu 1 dynsymcount 810 >   0x1b24efbcc000 .. 0x1b24efc7afff: /lib/libdtrace.so.2 > lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "libm.so.5") > lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") > lm_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so", "/lib") > lmp_find("/usr/local/lib/mdb/kvm/amd64/dtrace.so") > lm_find("/lib/libdtrace.so.2", "libxo.so.0") > lmp_find("/lib/libdtrace.so.2") > lm_find("/lib/libdtrace.so.2", "/lib") > lmp_find("/lib/libdtrace.so.2") > lm_find("/lib/libdtrace.so.2", "libthr.so.3") > lmp_find("/lib/libdtrace.so.2") > lm_find("/lib/libdtrace.so.2", "/lib") > lmp_find("/lib/libdtrace.so.2") > relocating "/usr/local/lib/mdb/kvm/amd64/dtrace.so" > relocating "/lib/libdtrace.so.2" > calling init function for /lib/libdtrace.so.2 at 0x1b24efc689cc > calling init function for /lib/libdtrace.so.2 at 0x1b24efc179a0 > calling init function for /lib/libdtrace.so.2 at 0x1b24efc420d0 > "getenv" in "libdtrace.so.2" ==> 0x1b24edfea3f0 in "libc.so.7" > "rd_init" in "libdtrace.so.2" ==> 0x1b24e9dd07d0 in "librtld_db.so.2" > calling init function for /usr/local/lib/mdb/kvm/amd64/dtrace.so at 0x1b24f41cacac > calling init function for /usr/local/lib/mdb/kvm/amd64/dtrace.so at > 0x1b24f41c49e0So far so good, I think.The module got loaded, libdtrace got > loaded as its dependency and then some dependencies Then I executed a command > that made a call into dtrace.so module. > "mdb_getopts" in "dtrace.so" ==> 0x1b1cc46b6760 in "mdb" > "mdb_readvar" in "dtrace.so" ==> 0x1b1cc46db470 in "mdb" > "mdb_vread" in "dtrace.so" ==> 0x1b1cc46db040 in "mdb" > "memset" in "dtrace.so" ==> 0x1b24edfde8f0 in "libc.so.7" > "dtrace_vopen" in "dtrace.so" ==> 0x1b24efc43320 in "libdtrace.so.2" > "elf_version" in "libdtrace.so.2" ==> 0x1b24eafbefe0 in "libelf.so.2" > "calloc" in "libdtrace.so.2" ==> 0x1b24edffd0a0 in "libc.so.7" > "dt_proc_init" in "libdtrace.so.2" ==> 0x1b24efc5be40 in "libdtrace.so.2" > "dt_zalloc" in "libdtrace.so.2" ==> 0x1b24efc61df0 in "libdtrace.so.2" > "pthread_mutex_init" in "libdtrace.so.2" ==> 0x1b24edf165d0 in "libc.so.7" > "pthread_cond_init" in "libdtrace.so.2" ==> 0x1b24edf163d0 in "libc.so.7" > "strdup" in "libdtrace.so.2" ==> 0x1b1cc46ed5a0 in "mdb" > "malloc" in "libdtrace.so.2" ==> 0x1b24edffc370 in "libc.so.7" > > (lots of output skipped) > > "dt_idstack_push" in "libdtrace.so.2" ==> 0x1b24efc360c0 in "libdtrace.so.2" > "dt_irlist_create" in "libdtrace.so.2" ==> 0x1b24efc1b240 in "libdtrace.so.2" > "yyinit" in "libdtrace.so.2" ==> 0x1b24efc3b030 in "libdtrace.so.2" > "strlen" in "libdtrace.so.2" ==> 0x1b24edfdfc30 in "libc.so.7" > "yybegin" in "libdtrace.so.2" ==> 0x1b24efc39b00 in "libdtrace.so.2" > "setjmp" in "libdtrace.so.2" ==> 0x1b24edf3ede0 in "libc.so.7" > "yyparse" in "libdtrace.so.2" ==> 0x1b1cc46fe300 in "mdb" > > The last line is what causes the trouble. > It's interesting that yyinit and yybegin were resolved correctly... ah, but > there are no such symbols in the main binary. > > Additional info: > > $ nm -D /usr/local/bin/mdb | grep yyparse > 00000000000b6300 T yyparse > > $ nm -D /usr/local/lib/mdb/kvm/amd64/dtrace.so| grep yyparse > $ > > $ nm -D /lib/libdtrace.so.2 | grep yyparse > 0000000000066460 T yyparse > > $ nm -D /usr/local/bin/mdb | grep yybegin > $ > > -- Andriy Gapon From nobody Sat Apr 19 10:25:28 2025 X-Original-To: current@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 4Zfnp33TdSz5t9wH for ; Sat, 19 Apr 2025 10:25:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zfnp26rSkz3fr3; Sat, 19 Apr 2025 10:25:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745058331; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=E+6SMmXgDiR0L9/8g4IcF+W0p3by1/6a4/qel6Kagg8=; b=xltH2mLwzbwuQslokhFYC/IRjv3ZoYlL1BuukNzFDVhKOz9gkkV8S0BRRiJh2La77dnaCj OChLJ6zx/iHLSwdlLzx+vEGhZZeiuUcM26h+IP9yGorsux5Q02tfRf9a768YmNCr9BBrjC nzUylmvjTZod5VZ8rS9QWh60B2QNVO8LrqOVmUFHOTeIOsYzotuUH1lhW/5djBsH6mtazd FiPVfXv6wPe3DrDKWGBt3F57ZdcNQ9Ij1GV/AszE4AP8Z/f5+5Tf3q2Bz99jFItHXvkl4P mGqdPatMz96dsXzja7XKSvml/5wlzVK+r5UK1kzm3l6kaJ6U1EqOvIulPBWmMw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745058331; a=rsa-sha256; cv=none; b=jpnFehztzdP6GoOSlFC79PN0TVBxf6/nPiC/16p8A8cOVnr4B75HqlmXdQNXpWQRIr1XTV 9jN74ibVhcWsy005GwedJQIH/ZOZhs/DPAYYk7TBi/MLkRH0ec6dQzlBWNB+vMUb8rnFqQ xizH4iyCMuDPM5JMYXjvku6B1KXl+FZEoRtBo6TYCc4h3zvVpyD6FVhQyKgB8Gn+gAhhz8 sIsr9K5J7bFfi6ul3Pu8zeI8LEjeGxgXP5EqxYMghVYl6YlQgOxQmSdDpf+0F9Ko0zOB5H K4zsnIaDVD701rILmNaONqq6O2hafAPwVV0qL/8tv0JJhoNTT5Ca/mA9i01qAA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745058331; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=E+6SMmXgDiR0L9/8g4IcF+W0p3by1/6a4/qel6Kagg8=; b=fbHlsXITkRGWt5XiO6hpfmEFEpGjzwDqHYsqjw/uxqrV3pyxeuPZQDl0Nbh2tNNV5MqTUF kXM11q0t6Ygq37G988nIM5c6D33qtBXeATjsPAO8bKuQnUPba6ym+VGmz5N0/jQUUebYqD qnYCWFktJz6BTmMcJSHNN4t8nXh0GNKZvb+DT752vRAds9SkaFtzGIJOUXAVSztGzodDKl N7qPiAH3HwaQg2PXBYv6D0IopSuD5kdYgS9Dm3VijdMRVLh969tX1PgOD/hv+x2nNzeux6 nGu3yRpFkJ3eUaezXsgauEQMNiTq7kDMdwXegysyxcWhzdt0H5+dII0M85NnIA== Received: from [192.168.0.88] (unknown [93.188.39.137]) (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) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zfnp23ZCgzCrb; Sat, 19 Apr 2025 10:25:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> Date: Sat, 19 Apr 2025 13:25:28 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RTLD_DEEPBIND question From: Andriy Gapon To: Konstantin Belousov Cc: FreeBSD Current References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> Content-Language: en-US Autocrypt: addr=avg@FreeBSD.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 19/04/2025 12:39, Andriy Gapon wrote: > On 19/04/2025 12:25, Andriy Gapon wrote: >> On 19/04/2025 02:41, Konstantin Belousov wrote: >>> RTLD_DEEPBIND works by first iterating over all (recursive) DT_NEEEDED >>> object for the object where the symbol is resolved, then by looking at >>> the global list of loaded objects. >>> Non-deepbind resolution is performed by looking at the global list. >>> >>> You can see it in the rtld.c:symlook_default(). > > From a quick look at the code, should we try to resolve the symbol in refobj > itself when it's marked with deepbind? Oh, and it looks like objects loaded under the "deepbind" object (e.g., needed objects) may not be aware that they are in the deepbind sub-tree? -- Andriy Gapon From nobody Sat Apr 19 10:29:09 2025 X-Original-To: current@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 4ZfntS1vrsz5t9xN for ; Sat, 19 Apr 2025 10:29:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4ZfntQ4hl5z3jh3; Sat, 19 Apr 2025 10:29:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 53JATADI045565; Sat, 19 Apr 2025 13:29:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 53JATADI045565 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 53JATAdP045564; Sat, 19 Apr 2025 13:29:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Apr 2025 13:29:09 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current Subject: Re: RTLD_DEEPBIND question Message-ID: References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4ZfntQ4hl5z3jh3 X-Spamd-Bar: ---- On Sat, Apr 19, 2025 at 01:25:28PM +0300, Andriy Gapon wrote: > On 19/04/2025 12:39, Andriy Gapon wrote: > > On 19/04/2025 12:25, Andriy Gapon wrote: > > > On 19/04/2025 02:41, Konstantin Belousov wrote: > > > > RTLD_DEEPBIND works by first iterating over all (recursive) DT_NEEEDED > > > > object for the object where the symbol is resolved, then by looking at > > > > the global list of loaded objects. > > > > Non-deepbind resolution is performed by looking at the global list. > > > > > > > > You can see it in the rtld.c:symlook_default(). > > > > From a quick look at the code, should we try to resolve the symbol in > > refobj itself when it's marked with deepbind? > Oh, and it looks like objects loaded under the "deepbind" object (e.g., > needed objects) may not be aware that they are in the deepbind sub-tree? But should they? Lets start with some minimal intrusive change: commit b4f4feb883a1be1d4ca3867f49baa20ce0c13d8d Author: Konstantin Belousov Date: Sat Apr 19 13:26:58 2025 +0300 rtld: symbolic and deepbind are equivalent for the refobj Reported by: avg diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index 2346c6eae9f6..8ea6afb43752 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -4679,12 +4679,13 @@ symlook_default(SymLook *req, const Obj_Entry *refobj) */ res = symlook_obj(&req1, refobj); if (res == 0 && (refobj->symbolic || - ELF_ST_VISIBILITY(req1.sym_out->st_other) == STV_PROTECTED)) { + ELF_ST_VISIBILITY(req1.sym_out->st_other) == STV_PROTECTED || + refobj->deepbind)) { req->sym_out = req1.sym_out; req->defobj_out = req1.defobj_out; assert(req->defobj_out != NULL); } - if (refobj->symbolic || req->defobj_out != NULL) + if (refobj->symbolic || req->defobj_out != NULL || refobj->deepbind) donelist_check(&donelist, refobj); if (!refobj->deepbind) From nobody Sat Apr 19 10:38:44 2025 X-Original-To: current@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 4Zfp5S5HZZz5tBdF for ; Sat, 19 Apr 2025 10:38:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4Zfp5R69qfz3nFg; Sat, 19 Apr 2025 10:38:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 53JAciZd046573; Sat, 19 Apr 2025 13:38:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 53JAciZd046573 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 53JAcieq046572; Sat, 19 Apr 2025 13:38:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Apr 2025 13:38:44 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current Subject: Re: RTLD_DEEPBIND question Message-ID: References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Result: default: False [2.83 / 15.00]; NEURAL_SPAM_LONG(0.99)[0.986]; NEURAL_SPAM_SHORT(0.93)[0.932]; NEURAL_SPAM_MEDIUM(0.91)[0.912]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4Zfp5R69qfz3nFg X-Spamd-Bar: ++ On Sat, Apr 19, 2025 at 01:29:15PM +0300, Konstantin Belousov wrote: > On Sat, Apr 19, 2025 at 01:25:28PM +0300, Andriy Gapon wrote: > > On 19/04/2025 12:39, Andriy Gapon wrote: > > > On 19/04/2025 12:25, Andriy Gapon wrote: > > > > On 19/04/2025 02:41, Konstantin Belousov wrote: > > > > > RTLD_DEEPBIND works by first iterating over all (recursive) DT_NEEEDED > > > > > object for the object where the symbol is resolved, then by looking at > > > > > the global list of loaded objects. > > > > > Non-deepbind resolution is performed by looking at the global list. > > > > > > > > > > You can see it in the rtld.c:symlook_default(). > > > > > > From a quick look at the code, should we try to resolve the symbol in > > > refobj itself when it's marked with deepbind? > > Oh, and it looks like objects loaded under the "deepbind" object (e.g., > > needed objects) may not be aware that they are in the deepbind sub-tree? > > But should they? > > Lets start with some minimal intrusive change: > And there is the version with the recursive marking by deepbind: diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index 2346c6eae9f6..9767c8e7016c 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -3824,27 +3824,26 @@ dlopen_object(const char *name, int fd, Obj_Entry *refobj, int lo_flags, if ((lo_flags & (RTLD_LO_EARLY | RTLD_LO_IGNSTLS)) == 0 && obj->static_tls && !allocate_tls_offset(obj)) { - _rtld_error("%s: No space available " - "for static Thread Local Storage", + _rtld_error( + "%s: No space available for static Thread Local Storage", obj->path); result = -1; } if (result != -1) result = load_needed_objects(obj, - lo_flags & - (RTLD_LO_DLOPEN | RTLD_LO_EARLY | - RTLD_LO_IGNSTLS | RTLD_LO_TRACE)); + lo_flags & (RTLD_LO_DLOPEN | RTLD_LO_EARLY | + RTLD_LO_IGNSTLS | RTLD_LO_TRACE | + RTLD_LO_DEEPBIND)); init_dag(obj); ref_dag(obj); if (result != -1) result = rtld_verify_versions(&obj->dagmembers); if (result != -1 && ld_tracing) goto trace; - if (result == -1 || - relocate_object_dag(obj, - (mode & RTLD_MODEMASK) == RTLD_NOW, &obj_rtld, - (lo_flags & RTLD_LO_EARLY) ? SYMLOOK_EARLY : 0, - lockstate) == -1) { + if (result == -1 || relocate_object_dag(obj, + (mode & RTLD_MODEMASK) == RTLD_NOW, &obj_rtld, + (lo_flags & RTLD_LO_EARLY) ? SYMLOOK_EARLY : 0, + lockstate) == -1) { dlopen_cleanup(obj, lockstate); obj = NULL; } else if (lo_flags & RTLD_LO_EARLY) { @@ -4679,12 +4678,13 @@ symlook_default(SymLook *req, const Obj_Entry *refobj) */ res = symlook_obj(&req1, refobj); if (res == 0 && (refobj->symbolic || - ELF_ST_VISIBILITY(req1.sym_out->st_other) == STV_PROTECTED)) { + ELF_ST_VISIBILITY(req1.sym_out->st_other) == STV_PROTECTED || + refobj->deepbind)) { req->sym_out = req1.sym_out; req->defobj_out = req1.defobj_out; assert(req->defobj_out != NULL); } - if (refobj->symbolic || req->defobj_out != NULL) + if (refobj->symbolic || req->defobj_out != NULL || refobj->deepbind) donelist_check(&donelist, refobj); if (!refobj->deepbind) From nobody Sat Apr 19 13:06:59 2025 X-Original-To: current@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 4ZfsNQ6HwYz5ssCQ for ; Sat, 19 Apr 2025 13:07:02 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4ZfsNP4BnFz3hj0 for ; Sat, 19 Apr 2025 13:07:01 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 53JD6xfx002015 for ; Sat, 19 Apr 2025 13:06:59 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 53JD6xHU002014 for current@freebsd.org; Sat, 19 Apr 2025 06:06:59 -0700 (PDT) (envelope-from david) Date: Sat, 19 Apr 2025 06:06:59 -0700 From: David Wolfskill To: current@freebsd.org Subject: graphics/drm-61-kmod build failure for main-n276560-83dcc133c876 Message-ID: Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NLkzrZQwDttmxz0w" Content-Disposition: inline X-Spamd-Result: default: False [2.03 / 15.00]; REPLYTO_EQ_TO_ADDR(5.00)[]; SIGNED_PGP(-2.00)[]; NEURAL_SPAM_LONG(0.93)[0.931]; NEURAL_HAM_SHORT(-0.80)[-0.798]; NEURAL_HAM_MEDIUM(-0.70)[-0.700]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; MISSING_XM_UA(0.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[catwhisker.org]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; MLMMJ_DEST(0.00)[current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_DKIM_NA(0.00)[]; HAS_REPLYTO(0.00)[current@freebsd.org] X-Rspamd-Queue-Id: 4ZfsNP4BnFz3hj0 X-Spamd-Bar: ++ --NLkzrZQwDttmxz0w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Running: FreeBSD g1-118.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #445 main-n= 276537-7121e9414f29: Fri Apr 18 12:36:30 UTC 2025 root@g1-120.catwhiske= r.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 after updating sources to main-n276560-83dcc133c876, with a ports tree at main-n703265-33b43edfb65d, I find: =2E.. --- i915_gem_mman.o --- /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-= kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/i915/gem/i915_gem_mman.c:= 171:77: error: call to undeclared function 'vm_page_next'; ISO C99 and late= r do not support implicit function declarations [-Werror,-Wimplicit-functio= n-declaration] 171 | for (vm_page_t page =3D vm_page_find_least(= vmobj, 0); page !=3D NULL; page =3D vm_page_next(page)) { | = ^ /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-= kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/i915/gem/i915_gem_mman.c:= 171:75: error: incompatible integer to pointer conversion assigning to 'vm_= page_t' (aka 'struct vm_page *') from 'int' [-Wint-conversion] 171 | for (vm_page_t page =3D vm_page_find_least(= vmobj, 0); page !=3D NULL; page =3D vm_page_next(page)) { | = ^ ~~~~~~~~~~~~~~~~~~ 2 errors generated. *** [i915_gem_mman.o] Error code 1 make[1]: stopped making "all" in /common/S4/obj/usr/src/amd64.amd64/sys/CAN= ARY/common/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/i915 make[1]: 1 error [end of excerpt from typescript -- dhw] This is using METAMODE (as I've done for ages, now); unfortunately: =2EERROR_TARGET=3D'all' =2EERROR_META_FILE=3D'' =2EMAKE.LEVEL=3D'2' MAKEFILE=3D'' so not much to be gained there (that I can see). I note that using the same ports tree, I had no issue with the similar update for stable/14, from stable/14-n271086-2a88aad6286d to stable/14-n271131-ee7a874557f4 (same machine; different slice). And yesterday's up date for head (main-n276506-a962800a09a4 to main-n276537-7121e9414f29, with the ports tree at main-n703215-0bca9d486f25) was uneventful. Peace, david --=20 David H. Wolfskill david@catwhisker.org "Checks and Balances" fails with sycophants in the other branches. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --NLkzrZQwDttmxz0w Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSTLzOSbomIK53fjFliipiWhXYx5QUCaAOf818UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTMy RjMzOTI2RTg5ODgyQjlEREY4QzU5NjI4QTk4OTY4NTc2MzFFNQAKCRBiipiWhXYx 5cI0AP9+FWDjyD5gJZnI3TMvBxFi2Pm76JrI01zX1DLPeSLuvwEA1PwxLdwScBMv YmvdMGvFKnz8cZJ6Dur3P5AlqRX4Ngs= =d7Jy -----END PGP SIGNATURE----- --NLkzrZQwDttmxz0w-- From nobody Sat Apr 19 13:21:59 2025 X-Original-To: current@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 4Zfsjj2LmRz5stY5 for ; Sat, 19 Apr 2025 13:22:01 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail.protected-networks.net", Issuer "R11" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zfsjj07dgz3tB8 for ; Sat, 19 Apr 2025 13:22:01 +0000 (UTC) (envelope-from imb@protected-networks.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:content-language:references :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1745068919; bh=9ldDjF3Clu8hSsz1RRJ+KQPEldHuYGudEV8C LDCnlhc=; b=Pxtdw5hdMVAvTkXfoCRAtpKMWrW/ldvNHFCZ0elLSKp92OZewpkZ MxklbDiZT2T9rM5exuBoxmPTJkRIcqZecnn30u3BP4MVYhy+Sa842GXeyQfd1Bj/ eWyz22utNpbG9J9j2UDDmq4niH4BX+QEiLJxm39A+v9Kvm7EVcoiCF0= Received: from [192.168.1.9] (d5540.auburn.protected-networks.net [192.168.1.9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 74CC227F42 for ; Sat, 19 Apr 2025 09:21:59 -0400 (EDT) Message-ID: <6ef56f73-f103-4fe4-ab77-cf732ae1bb45@protected-networks.net> Date: Sat, 19 Apr 2025 09:21:59 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: graphics/drm-61-kmod build failure for main-n276560-83dcc133c876 To: current@freebsd.org References: Content-Language: en-NZ From: Michael Butler In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US] X-Rspamd-Queue-Id: 4Zfsjj07dgz3tB8 X-Spamd-Bar: ---- commit a3a88ed appears to have removed the function(s) needed by drm kmod to build and run :-( Michael On 4/19/25 09:06, David Wolfskill wrote: > Running: > FreeBSD g1-118.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #445 main-n276537-7121e9414f29: Fri Apr 18 12:36:30 UTC 2025 root@g1-120.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 > > after updating sources to main-n276560-83dcc133c876, with a ports tree > at main-n703265-33b43edfb65d, I find: > > ... > --- i915_gem_mman.o --- > /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/i915/gem/i915_gem_mman.c:171:77: error: call to undeclared function 'vm_page_next'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] > 171 | for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) { > | ^ > /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/i915/gem/i915_gem_mman.c:171:75: error: incompatible integer to pointer conversion assigning to 'vm_page_t' (aka 'struct vm_page *') from 'int' [-Wint-conversion] > 171 | for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) { > | ^ ~~~~~~~~~~~~~~~~~~ > 2 errors generated. > *** [i915_gem_mman.o] Error code 1 > > make[1]: stopped making "all" in /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/i915 > make[1]: 1 error > [end of excerpt from typescript -- dhw] > > This is using METAMODE (as I've done for ages, now); unfortunately: > > .ERROR_TARGET='all' > .ERROR_META_FILE='' > .MAKE.LEVEL='2' > MAKEFILE='' > > so not much to be gained there (that I can see). > > > I note that using the same ports tree, I had no issue with the > similar update for stable/14, from stable/14-n271086-2a88aad6286d > to stable/14-n271131-ee7a874557f4 (same machine; different slice). > > And yesterday's up date for head (main-n276506-a962800a09a4 to > main-n276537-7121e9414f29, with the ports tree at > main-n703215-0bca9d486f25) was uneventful. > > Peace, > david From nobody Sat Apr 19 14:02:31 2025 X-Original-To: current@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 4ZftcX4DG1z5sxTw for ; Sat, 19 Apr 2025 14:02:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZftcX0z9kz3Hqs for ; Sat, 19 Apr 2025 14:02:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x834.google.com with SMTP id d75a77b69052e-47677b77725so29553611cf.3 for ; Sat, 19 Apr 2025 07:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745071354; x=1745676154; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=ciMPkgyjX+cLP93eA4QEneSrKP2psFCxqnUVow0M/oo=; b=AKl1/4W3q/IxOX0mcwx0D2zaK/jPBNdfRfR/hPgB4pf5kBNDQzRB788rP9Y0NGhfyd 135Of89IUbKKU/mNLGUo2s2GYgzmDbin+Mgn0xdBJ+qew5dqFt38OLra167NiZhyJMAc GtJBqBRnn9Zo7njD601oTXFlc0zhlMeukre0QN7n+kMn12z6tGHR4xid6P5mTcfZwtmR OJ1RKcn92S7R7WzMdA4clt3mV76pgQpFyUVQsLzdUXDcLFsKby1086q9N/A0yXeyM0cx +9CFUWbEa67m1a4MgXntrxlfkQAZrVuzGRgR2WItOqNQiGoBEh5Ie60ayOy8cwmPenWq ETcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745071354; x=1745676154; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:sender:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=ciMPkgyjX+cLP93eA4QEneSrKP2psFCxqnUVow0M/oo=; b=n5GIXFi0yRuH9+MEzBVTancqmWDCcA1CFgobTliW5RpVTvmrfQ51ShOAAqvq1SY4xD uhnu5z6e1s9gXNyZd2MU92o4c/zy3Ek6MR6Lod5VURZool6EDvCzJAVJ+LR0Y3bbRwIw D/MQuUYLSteAD+MbAjBUmB+Zc0LmN3TpukFyN+e1C06KjHBV39+vlTRJCk6gfIKghg4/ IiwrOLKH4KhDL/t+c0/J7qeXvfypLu0aRKT1dSVZyH2AY2pQ7GVJb0X9dKZCnZiEtjJy /sVnO8dLvMZT9Nw/KoJeSHDADnBqAAVyxb7qSXjXSadCvezfLXFGR4HOKamAehbo1XSx ubsg== X-Gm-Message-State: AOJu0YyF0Q6EIKEfefbL/5N3clkLwWrEBUfOuzyYKtsgPfkJ1GIv0xyT JSblbiDY9ZG+7C/+fse0Sy21zxprBFBCexFm7uvLlOESSAWRlBlGQYorNVzr X-Gm-Gg: ASbGnctiw5v7gY03uVfjv1ZgH24GTNw2GKd3YkgqnHwmLb3BZBwyNymA88pwS6u8DMH 4ZK1jlZqCl39Ctqc2Pmlw0iSVRmOzArM+SQI3FA8QXHOKi3b/oJmKkjYJnvDC2CEK87zQ2oHp8f vl4Be98og+5bZytfZOnWfbeCp7UhilxzqyiezLARTxQHFGAyvRaSCumZDKGuWfC9pawvrtNLmlw 4g9xxI44rMbngP8wm8351QhS5g1OO/nvT4QFKLv7O5rlYsKU6ou+ezCDgnNA87v8Is8xXVhvmLT obSi47AoyLDP+QjVWfHs8BJu7oj4mWgXGyuHHzYRRXzBD4MYQSygAUMRAQpcKsSXIw== X-Google-Smtp-Source: AGHT+IG6x3Amxb4VC8S6lKNXZwkb+sAdmwxdttZs7VwPPVJtm/bvTvgpLU7vYWazSsW/Q42Upc2M7w== X-Received: by 2002:ac8:7f8e:0:b0:477:6f4a:adb9 with SMTP id d75a77b69052e-47aec350b40mr101792971cf.5.1745071354025; Sat, 19 Apr 2025 07:02:34 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-47ae9c16df4sm21530651cf.1.2025.04.19.07.02.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 19 Apr 2025 07:02:33 -0700 (PDT) Date: Sat, 19 Apr 2025 10:02:31 -0400 From: Mark Johnston To: current@freebsd.org Subject: Re: graphics/drm-61-kmod build failure for main-n276560-83dcc133c876 Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4ZftcX0z9kz3Hqs X-Spamd-Bar: ---- On Sat, Apr 19, 2025 at 06:06:59AM -0700, David Wolfskill wrote: > Running: > FreeBSD g1-118.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #445 main-n276537-7121e9414f29: Fri Apr 18 12:36:30 UTC 2025 root@g1-120.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 > > after updating sources to main-n276560-83dcc133c876, with a ports tree > at main-n703265-33b43edfb65d, I find: > > ... > --- i915_gem_mman.o --- > /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/i915/gem/i915_gem_mman.c:171:77: error: call to undeclared function 'vm_page_next'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] > 171 | for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) { > | ^ > /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/i915/gem/i915_gem_mman.c:171:75: error: incompatible integer to pointer conversion assigning to 'vm_page_t' (aka 'struct vm_page *') from 'int' [-Wint-conversion] > 171 | for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) { > | ^ ~~~~~~~~~~~~~~~~~~ > 2 errors generated. > *** [i915_gem_mman.o] Error code 1 > > make[1]: stopped making "all" in /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/i915 > make[1]: 1 error > [end of excerpt from typescript -- dhw] > > This is using METAMODE (as I've done for ages, now); unfortunately: > > .ERROR_TARGET='all' > .ERROR_META_FILE='' > .MAKE.LEVEL='2' > MAKEFILE='' > > so not much to be gained there (that I can see). Something like the following diff is needed. It needs to be built against the latest main, where __FreeBSD_version is bumped. diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index 2a9946c7d0..f61eeefe7a 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c @@ -34,6 +34,7 @@ #include #include #include +#include #endif #ifdef __linux__ /* Mute unused function warning. */ @@ -168,9 +169,16 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data, if ((rv == KERN_SUCCESS) && (args->flags & I915_MMAP_WC)) { VM_OBJECT_WLOCK(vmobj); if (vm_object_set_memattr(vmobj, VM_MEMATTR_WRITE_COMBINING) != KERN_SUCCESS) { - for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) { +#if __FreeBSD_version >= 1500038 + struct pctrie_iter pages; + vm_page_t page; + + vm_page_iter_init(&pages, vmobj); + VM_RADIX_FORALL(page, &pages) +#else + for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) +#endif pmap_page_set_memattr(page, VM_MEMATTR_WRITE_COMBINING); - } } VM_OBJECT_WUNLOCK(vmobj); } From nobody Sun Apr 20 02:50:48 2025 X-Original-To: freebsd-current@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 4ZgCg61p4xz5trBk for ; Sun, 20 Apr 2025 02:50:58 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZgCg45yqxz3vkV for ; Sun, 20 Apr 2025 02:50:56 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ultimatedns.net header.s=mx99 header.b=kqGD5gSS; dmarc=pass (policy=none) header.from=bsdforge.com; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53K2onGR020884 for ; Sat, 19 Apr 2025 19:50:55 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1745117455; x=1745118055; r=y; bh=39QQsGTKhYR9JwAcZg7lS2jLe2p2HHZOfT1vxu6M/gM=; h=Date:From:To:Subject; b=kqGD5gSSBKeApldyBL0LNXJlrdJGZ1SSGsMZv8J5jf3Zg2EfGL4OThTnMdEtR+j6p KNFPndY8Mvy+UMeNgnj+k90CgmE4A7nC1r9/JjfTs36vdZzLB1Hp/AcUmKIsAoP9Zm IT0qFwjCg0r1LKALuXxSu/hSYNVJomO89IRJQNTZpc5QuqocWWr8CEqxEaKJXkIOiw 0FQ0ACE+96xBfSmWmjiLfjtnbfD+i8XeCg9mRr2Xjwd37m9DFVCtofhGUIlbPtzL7r qOXvuXf2vvPMiI605wL7Ce2/coFW3/1+EcaujHtyJ16lLB7I1mmt4nlpS6OfqRKbZW MwiQ5zJMSUBSA== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Sat, 19 Apr 2025 19:50:48 -0700 From: Chris To: freebsd-current Subject: =?UTF-8?Q?New_kernel_doesn=E2=80=99t_recognize_ufs_gpt_root_file?= =?UTF-8?Q?system?= User-Agent: UDNSMS/17.0 Message-ID: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_3628868cd237d41cdf6eca56f6e98632" X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [-0.70 / 15.00]; DMARC_POLICY_ALLOW(-0.50)[bsdforge.com,none]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip4:24.113.41.81/29]; R_DKIM_ALLOW(-0.20)[ultimatedns.net:s=mx99]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MIME_UNKNOWN(0.10)[application/pgp-keys]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; FROM_HAS_DN(0.00)[]; HAS_ATTACHMENT(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; local_wl_ip(0.00)[24.113.41.81]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[ultimatedns.net:+] X-Rspamd-Queue-Id: 4ZgCg45yqxz3vkV X-Spamd-Bar: / --=_3628868cd237d41cdf6eca56f6e98632 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Finally got a build world/kernel to complete. Following a installkernel with a boot -s resulted in the inability to mount root (/dev/gpt/FBSD15) It’s a ufs2 filesystem. I booted the 15-CURRENT usb stick. It recognized it. I performed fsck on it. No errors. An attempt to mount it from the new kernel at boot is: Mounting from ufs:/dev/gpt/FBSD15 failed with error 19. Can anyone suggest the best way forward please? Thanks. —-Chris -- sent from hardware written from and running on FreeBSD --=_3628868cd237d41cdf6eca56f6e98632 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_3628868cd237d41cdf6eca56f6e98632-- From nobody Sun Apr 20 03:36:43 2025 X-Original-To: freebsd-current@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 4ZgDh92Mykz5ttfD for ; Sun, 20 Apr 2025 03:36:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZgDh86Vw8z3Kn6 for ; Sun, 20 Apr 2025 03:36:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-3031354f134so2290174a91.3 for ; Sat, 19 Apr 2025 20:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1745120215; x=1745725015; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zrOH/wXlYpMYguXGOrbWnYX9VWsBCtEnqNkBlc9t3zs=; b=uXd5nQnnG7ncV9wLOXAJzGXxicG7JEIXt4PERS75VtZNkxZGHwbz4Je2j0fZ2wBdMJ XC2NxMzcyHquhwO7y9/7Vpz0ghw1tVGm4i5zvhlVDJj4VSPR61jxVmZLGKZInDtqqErY CXpiyn6wtlazE2tfV0piBoEZicWD1ZHE3/vgRQbxXg5lHKTs4rra7CipyotC3LoiQUow tVQc+ywHnau8+aNzCuA7ah36rOzDbpj0lize73O4UlomiNRn6G+rtSsqReWnosSrIsaD NIYSJ3RvM8uJzSqI2mWWI6PyuUbJd1ZlsOiincJyIh5N9eRCJvWIKP9EC1jVP5shA1Gf TyOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745120215; x=1745725015; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zrOH/wXlYpMYguXGOrbWnYX9VWsBCtEnqNkBlc9t3zs=; b=tEhkXtd0E4/R7I42YKSY2rsH1NKGlaFHn0FDsLLdj9J8PUGJaOcd+MoMVsNIvT1ZZA 3YDIBqp2m/qwmxXYK0HUT7qOHo2wtRMUKufh2FyGo6moCDwwefMhcuy7VpyhKq8UqYTS 2pBLWtf5gbQgwff+DdiQfjX35vNVheenOeTL0+0/69Dyv8OCHOo8IrmvYNhD9b/YH5kf hRJ6Zd/kHnhnzH/gECIDI7G0azhzndK87zPE2crsUwYMJP2TmRpvkKzJmiZHc2wBOpdH mzywsUIC6JcEYOb6DdJDLFDvWRLmB9vaJ4b+jqkohGdi1L+ueiLof8BbqWlEr/CGSnZl N/Jg== X-Gm-Message-State: AOJu0YzI5cSwGzpjZve54iypYfl9VU2H0y/iGbvnm26Sp4SE1GhA5wBn J5oAefNYXES4j3hFv+lxybokO+yNplHBT+bhherIOGOPqH+WYFTo973vF2tJKilXbkoC4Yd9HJa hnEouxHqN02ImY8OuXpzITp2c2gWH/qyv42UKZH78FHFDrF9E X-Gm-Gg: ASbGnctHK5f6/iSF4TSYCoFiISVPzhShO/HsdYgkxDaeYHq1VEZ8/0oAYxGtbYjLItE NC88rqh62Jjju0V6O3HpOKbIm7kdI+Jc11N1lwOxCjTnoi/BHJLi39oBQBphZeSSPYbcgClDXEE e+d/8wC/5bLjLOT5nH/mrGwU4rkC947yJzfuDq6jYW7elMSJwAdqT6 X-Google-Smtp-Source: AGHT+IH1Z4czwrdtCxb562ofSjrJJiSvZOMHb0uCX8c6VQvGvIbCspj5oqAdIJeFjEadqp2XvED9PjMVX0/JAB4Qhy4= X-Received: by 2002:a17:90b:498f:b0:2fe:8282:cb9d with SMTP id 98e67ed59e1d1-3087bbb7085mr10998215a91.28.1745120215102; Sat, 19 Apr 2025 20:36:55 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> In-Reply-To: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> From: Warner Losh Date: Sat, 19 Apr 2025 21:36:43 -0600 X-Gm-Features: ATxdqUF5NgG1HpvUNolPwF2iJaSP8b5VOPnHZo4iev1_2Zw3EZqObNMCI_d7ad8 Message-ID: Subject: =?UTF-8?Q?Re=3A_New_kernel_doesn=E2=80=99t_recognize_ufs_gpt_root_file?= =?UTF-8?Q?system?= To: Chris Cc: freebsd-current Content-Type: multipart/alternative; boundary="000000000000830dc206332d7630" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4ZgDh86Vw8z3Kn6 X-Spamd-Bar: ---- --000000000000830dc206332d7630 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 19, 2025, 8:51=E2=80=AFPM Chris wrote: > Finally got a build world/kernel to complete. Following a > installkernel with a boot -s resulted in the inability > to mount root (/dev/gpt/FBSD15) > It=E2=80=99s a ufs2 filesystem. I booted the 15-CURRENT > usb stick. It recognized it. I performed fsck on > it. No errors. > An attempt to mount it from the new kernel at boot is: > Mounting from ufs:/dev/gpt/FBSD15 failed with error 19. > > Can anyone suggest the best way forward please? > Maybe this is a custom kernel without the label code. What does '?' at mountroot> prompt say? Does one of those work if you add 'ufs:/dev/' to the front of each of the geoms listed? Most likely ada0p2 or nda0p2. Warner Thanks. > > =E2=80=94-Chris > > -- > sent from hardware written from and running on FreeBSD --000000000000830dc206332d7630 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Apr 19, 2025, 8:51=E2=80= =AFPM Chris <bsd-lists@bsdforg= e.com> wrote:
Finally got a = build world/kernel to complete. Following a
installkernel with a boot -s resulted in the inability
to mount root (/dev/gpt/FBSD15)
It=E2=80=99s a ufs2 filesystem. I booted the 15-CURRENT
usb stick. It recognized it. I performed fsck on
it. No errors.
An attempt to mount it from the new kernel at boot is:
Mounting from ufs:/dev/gpt/FBSD15 failed with error 19.

Can anyone suggest the best way forward please?

Maybe this is a custom kerne= l without the label code. What does '?' at mountroot> prompt say= ? Does one of those work if you add 'ufs:/dev/' to the front of eac= h of the geoms listed? Most likely ada0p2 or nda0p2.

Warner

Thanks.

=E2=80=94-Chris

--
sent from hardware written from and running on FreeBSD
--000000000000830dc206332d7630-- From nobody Sun Apr 20 05:23:10 2025 X-Original-To: freebsd-current@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 4ZgH2v68yyz5v1HD for ; Sun, 20 Apr 2025 05:23:19 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZgH2t74hJz48Hv for ; Sun, 20 Apr 2025 05:23:18 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53K5NBoc056156; Sat, 19 Apr 2025 22:23:17 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1745126597; x=1745127197; r=y; bh=pxy/JcbI1PDtGeg/IL1X78Om4zmCEWWA15GZZyE9yrc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=jGzIp/n1qXaXcMpkdI1mE+G4E2TOxCsjWJShwC9Gp6LDQ61F05pTo/utQDQBDaRzA iQa5xPfSy5o3TjHma6izyJ9gB0hVP5L0KWbidataJWq6tJO6nXuoFFwQVhiDJxUzt+ ZtxpBYZkj0ONUF5RUXOfJtJOHp2T//VvBqu37fqvOpK+v9h7JvO1F7OH4ISR8Ez02+ xwouF+FX55wm0d2bTbGLw/ux7fTqAUgw5NiqqpAxBRE7JXIpASSSYYILV8AhRcsWgd Y5sxNaHuJVIzeR5/VBOBDLj5Cg04Oeij9YXt/VRaR7jk1f87eFiXsIpC68Cg9KDhYa wLi2dk/Q7+r5w== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Sat, 19 Apr 2025 22:23:10 -0700 From: Chris To: Warner Losh Cc: freebsd-current Subject: =?UTF-8?Q?Re=3A_New_kernel_doesn=E2=80=99t_recognize_ufs_gpt_roo?= =?UTF-8?Q?t_filesystem?= In-Reply-To: References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_9aac49bf3bf94afd665cf1731afbf9d0" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4ZgH2t74hJz48Hv X-Spamd-Bar: ---- --=_9aac49bf3bf94afd665cf1731afbf9d0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-04-19 20:36, Warner Losh wrote: > On Sat, Apr 19, 2025, 8:51 PM Chris wrote: > >> Finally got a build world/kernel to complete. Following a >> installkernel with a boot -s resulted in the inability >> to mount root (/dev/gpt/FBSD15) >> It’s a ufs2 filesystem. I booted the 15-CURRENT >> usb stick. It recognized it. I performed fsck on >> it. No errors. >> An attempt to mount it from the new kernel at boot is: >> Mounting from ufs:/dev/gpt/FBSD15 failed with error 19. >> >> Can anyone suggest the best way forward please? >> > > Maybe this is a custom kernel without the label code. It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But I'm using the same kernconf as before. Was label removed from generic in the last 11 mos.? > What does '?' at > mountroot> prompt say? nadda, nothing. > Does one of those work if you add 'ufs:/dev/' to the > front of each of the geoms listed? Most likely ada0p2 or nda0p2. Indeed. It's nda0p2. But ufs:/dev/nda0p2 returns the same error 19. I had to move kernel to kernel.new && kernel.old to kernel to get here to write this response. Thanks! --Chris > > Warner > > Thanks. >> >> —-Chris -- sent from hardware written from and running on FreeBSD --=_9aac49bf3bf94afd665cf1731afbf9d0 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_9aac49bf3bf94afd665cf1731afbf9d0-- From nobody Sun Apr 20 06:17:17 2025 X-Original-To: freebsd-current@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 4ZgJFL4DQpz5v4P1 for ; Sun, 20 Apr 2025 06:17:26 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZgJFK4Pyvz3Wd7 for ; Sun, 20 Apr 2025 06:17:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ultimatedns.net header.s=mx99 header.b=SrIAJ6aC; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53K6HID4067688; Sat, 19 Apr 2025 23:17:24 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1745129844; x=1745130444; r=y; bh=l/rQfktlpXZ5zq8xCyb6IS3liCSygVT5Xcq4fXLbddE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=SrIAJ6aC+JRuChekpbLj7dnbAab//Nm9ZbLN9wt4w1l5DOKddmBVVrQzOtJX+3hKJ NcmcnExSH1JImRwIq7S6ERLj3bawKmGO9Mkni6z+5bhwhdO09oNJrpi0aZOq9IcmSm UshRRFA/63nAeE6MM1QoLaFfR6ryAKluuTMjIU+Y8pD364ehaGj9tx/SAyKyyhyehh VsR5RtTSjrhx86cRoVA9HVwzS4Q03Xjxh2k6WvyTceb05a+9eCLVs1H+hyQxBBUKxx aXvYv5f1tgszTAHI925v/TVZ08pucIH79WUR6wUXZdfZ/s3Qgc94Stxqwj1soVkSj3 Jr/PhfAYOk59w== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Sat, 19 Apr 2025 23:17:17 -0700 From: Chris To: Warner Losh Cc: freebsd-current Subject: =?UTF-8?Q?Re=3A_New_kernel_doesn=E2=80=99t_recognize_ufs_gpt_roo?= =?UTF-8?Q?t_filesystem?= In-Reply-To: <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_6db49f3401ca54002a272a96de226d8a" X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [-0.20 / 15.00]; R_DKIM_ALLOW(-0.20)[ultimatedns.net:s=mx99]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip4:24.113.41.81/29]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MIME_UNKNOWN(0.10)[application/pgp-keys]; HAS_ATTACHMENT(0.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[ultimatedns.net:+] X-Rspamd-Queue-Id: 4ZgJFK4Pyvz3Wd7 X-Spamd-Bar: / --=_6db49f3401ca54002a272a96de226d8a Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-04-19 22:23, Chris wrote: > On 2025-04-19 20:36, Warner Losh wrote: >> On Sat, Apr 19, 2025, 8:51 PM Chris wrote: >> >>> Finally got a build world/kernel to complete. Following a >>> installkernel with a boot -s resulted in the inability >>> to mount root (/dev/gpt/FBSD15) >>> It’s a ufs2 filesystem. I booted the 15-CURRENT >>> usb stick. It recognized it. I performed fsck on >>> it. No errors. >>> An attempt to mount it from the new kernel at boot is: >>> Mounting from ufs:/dev/gpt/FBSD15 failed with error 19. >>> >>> Can anyone suggest the best way forward please? >>> >> >> Maybe this is a custom kernel without the label code. > It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But > I'm using the same kernconf as before. Was label removed from generic > in the last 11 mos.? Of course not. I have GEOM_LABEL in my kernconf. FWIW old vs. new kernel indicates I gained +acpi_sbl_wmi.ko +bnxt_re.ko +dummymbuf.ko +gpioaei.ko +if_iwx.ko +if_mtw.ko +if_rtw89.ko +mac_do.ko +p9fs.ko +snd_dummy.ko +umb.ko +virtio_p9fs.ko +wlan_gcmp.ko and this was removed. No, root is not on gvinum -geom_vinum.ko > >> What does '?' at >> mountroot> prompt say? > nadda, nothing. > >> Does one of those work if you add 'ufs:/dev/' to the >> front of each of the geoms listed? Most likely ada0p2 or nda0p2. > Indeed. It's nda0p2. But ufs:/dev/nda0p2 returns the same error 19. > I had to move kernel to kernel.new && kernel.old to kernel to get > here to write this response. > > Thanks! > > --Chris >> >> Warner >> >> Thanks. >>> >>> —-Chris -- sent from hardware written from and running on FreeBSD --=_6db49f3401ca54002a272a96de226d8a Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_6db49f3401ca54002a272a96de226d8a-- From nobody Sun Apr 20 08:13:09 2025 X-Original-To: current@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 4ZgLpw6RB4z5skMy for ; Sun, 20 Apr 2025 08:13:12 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from mx-2023-1.gwdg.de (mx-2023-1.gwdg.de [134.76.10.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZgLpw2s0Jz3KGw; Sun, 20 Apr 2025 08:13:12 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gwdg.de; s=2023-rsa; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: Reply-To:CC:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=xmuY8571yRNqvS0LqLXSrDkvh2GRIAZ+/e484ADrb+s=; b=bgWzYAYK5LOPG/Y78JkoRvsEJS hFHWGUuW/VijxT5JkL/QNPDLNwVMuzWwCJpVSnNpCaK5t+YpOcBhw8FUpk1iq6YQt0u8bf/sFIS/I h+BeGuJ5meBPwBew/WVNoUWMg0oxfbMXc9V+X2ixhYidytWK/hInepMSuZAbfVkU4XOVVMH7TB/64 dlkJfpvwKRUupv8tV85GNIKTT+VtPCAz7Qv3/+pGIjdmzT79RPzZe8jKclugPk2btoI2jelxz1KKj t8qwOhnI9DSc7CYcicR6M11j+WmZvlyO1ilqb+fYBqb24iO6Q+Ax9cQ9YoUoscHlxKmnx7AyVj72L bnLQUOpw==; Received: from xmailer.gwdg.de ([134.76.10.29]:56701) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1u6PnX-009D11-1y; Sun, 20 Apr 2025 10:13:07 +0200 Received: from mbx19-gwd-03.um.gwdg.de ([10.108.142.56] helo=email.gwdg.de) by mailer.gwdg.de with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (GWDG Mailer) (envelope-from ) id 1u6Pna-0007Uo-07; Sun, 20 Apr 2025 10:13:10 +0200 Received: from [192.168.178.23] (10.250.9.200) by MBX19-GWD-03.um.gwdg.de (10.108.142.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.14; Sun, 20 Apr 2025 10:13:09 +0200 Message-ID: <4a8bd5c1-6811-4e9e-b8e9-5fd6def79dec@gwdg.de> Date: Sun, 20 Apr 2025 10:13:09 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: graphics/drm-61-kmod build failure for main-n276560-83dcc133c876 Content-Language: en-US, de-DE To: Mark Johnston References: CC: Reply-To: Rainer Hurling From: Rainer Hurling In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.250.9.200] X-ClientProxiedBy: mbx19-sub-01.um.gwdg.de (10.108.142.54) To MBX19-GWD-03.um.gwdg.de (10.108.142.56) X-Virus-Scanned: (clean) by clamav X-Spam-Level: - X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:207592, ipnet:134.76.0.0/16, country:DE] X-Rspamd-Queue-Id: 4ZgLpw2s0Jz3KGw X-Spamd-Bar: ---- Am 19.04.25 um 16:02 schrieb Mark Johnston: > On Sat, Apr 19, 2025 at 06:06:59AM -0700, David Wolfskill wrote: >> Running: >> FreeBSD g1-118.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #445 main-n276537-7121e9414f29: Fri Apr 18 12:36:30 UTC 2025 root@g1-120.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 >> >> after updating sources to main-n276560-83dcc133c876, with a ports tree >> at main-n703265-33b43edfb65d, I find: >> >> ... >> --- i915_gem_mman.o --- >> /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/i915/gem/i915_gem_mman.c:171:77: error: call to undeclared function 'vm_page_next'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] >> 171 | for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) { >> | ^ >> /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/i915/gem/i915_gem_mman.c:171:75: error: incompatible integer to pointer conversion assigning to 'vm_page_t' (aka 'struct vm_page *') from 'int' [-Wint-conversion] >> 171 | for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) { >> | ^ ~~~~~~~~~~~~~~~~~~ >> 2 errors generated. >> *** [i915_gem_mman.o] Error code 1 >> >> make[1]: stopped making "all" in /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/i915 >> make[1]: 1 error >> [end of excerpt from typescript -- dhw] >> >> This is using METAMODE (as I've done for ages, now); unfortunately: >> >> .ERROR_TARGET='all' >> .ERROR_META_FILE='' >> .MAKE.LEVEL='2' >> MAKEFILE='' >> >> so not much to be gained there (that I can see). > > Something like the following diff is needed. It needs to be built > against the latest main, where __FreeBSD_version is bumped. > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c > index 2a9946c7d0..f61eeefe7a 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > #endif > > #ifdef __linux__ /* Mute unused function warning. */ > @@ -168,9 +169,16 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data, > if ((rv == KERN_SUCCESS) && (args->flags & I915_MMAP_WC)) { > VM_OBJECT_WLOCK(vmobj); > if (vm_object_set_memattr(vmobj, VM_MEMATTR_WRITE_COMBINING) != KERN_SUCCESS) { > - for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) { > +#if __FreeBSD_version >= 1500038 > + struct pctrie_iter pages; > + vm_page_t page; > + > + vm_page_iter_init(&pages, vmobj); > + VM_RADIX_FORALL(page, &pages) > +#else > + for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) > +#endif > pmap_page_set_memattr(page, VM_MEMATTR_WRITE_COMBINING); > - } > } > VM_OBJECT_WUNLOCK(vmobj); > } > As expected, this error also happens with graphics/drm-66-kmod : ===> i915 (all) cc -O2 -pipe -fno-strict-aliasing -DLINUXKPI_VERSION=60600 '-DKBUILD_MODNAME="i915kms"' '-DLINUXKPI_PARAM_PREFIX=i915_' -DDRM_SYSCTL_PARAM_PREFIX=_i915kms -DCONFIG_DRM_AMDGPU_CIK -DCONFIG_DRM_AMDGPU_SI -DCONFIG_DRM_AMD_DC -DCONFIG_DRM_AMD_DC_SI -DCONFIG_AMD_PMC -DCONFIG_DRM_EXEC -DCONFIG_DRM_I915_FORCE_PROBE='"*"' -DCONFIG_DRM_I915_REQUEST_TIMEOUT=20000 -DCONFIG_DRM_I915_CAPTURE_ERROR -DCONFIG_DRM_I915_USERFAULT_AUTOSUSPEND=250 -DCONFIG_DRM_I915_STOP_TIMEOUT=100 -DCONFIG_DRM_I915_PREEMPT_TIMEOUT=640 -DCONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE=7500 -DCONFIG_DRM_I915_HEARTBEAT_INTERVAL=2500 -DCONFIG_DRM_I915_TIMESLICE_DURATION=1 -DCONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT=8000 -DCONFIG_DRM_I915_FENCE_TIMEOUT=10000 -DCONFIG_DRM_MIPI_DSI -DCONFIG_DRM_PANEL_ORIENTATION_QUIRKS -DCONFIG_APERTURE_HELPERS -DCONFIG_DRM_FBDEV_EMULATION -DCONFIG_DRM_FBDEV_OVERALLOC=100 -DCONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG -DCONFIG_BACKLIGHT_CLASS_DEVICE -DCONFIG_DEBUG_FS -DCONFIG_DMI -DCONFIG_FB -DCONFIG_MTRR -DCONFIG_PCI -DCONFIG_PM -DCONFIG_PM_SLEEP -DCONFIG_SMP -DCONFIG_SUSPEND -DCONFIG_VIDEO_CMDLINE -DCONFIG_ACPI -DCONFIG_ACPI_SLEEP -DCONFIG_X86 -DCONFIG_X86_PAT -DCONFIG_64BIT -DCONFIG_AS_MOVNTDQA -DCONFIG_COMPAT -DCONFIG_X86_64 -DCONFIG_DRM_AMD_DC_FP -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/linuxkpi/gplv2/include -I/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/linuxkpi/bsd/include -I/usr/src/sys/compat/linuxkpi/common/include -I/usr/src/sys/compat/linuxkpi/dummy/include -I/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/include -I/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/include/drm -I/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/include/uapi -I/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/drivers/gpu -I/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/drivers/gpu/drm/i915 -I/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/drivers/gpu/drm/i915/display -include /usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/obj/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/i915/opt_global.h -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -MD -MF.depend.i915_gem_mman.o -MTi915_gem_mman.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wswitch -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -Wno-pointer-arith -Wno-format -Wno-cast-qual -Wno-unused-but-set-variable -mno-aes -mno-avx -std=gnu17 -c /usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/drivers/gpu/drm/i915/gem/i915_gem_mman.c -o i915_gem_mman.o /usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/drivers/gpu/drm/i915/gem/i915_gem_mman.c:171:77: error: call to undeclared function 'vm_page_next'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration] 171 | for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) { | ^ /usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/drivers/gpu/drm/i915/gem/i915_gem_mman.c:171:75: error: incompatible integer to pointer conversion assigning to 'vm_page_t' (aka 'struct vm_page *') from 'int' [-Wint-conversion] 171 | for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page)) { | ^ ~~~~~~~~~~~~~~~~~~ 2 errors generated. *** Error code 1 Stop. make[1]: stopped making "all" in /usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_2/i915 The patch from Mark also applies for drm-66-kmod, builds and installs fine. Many thanks! From nobody Sun Apr 20 08:15:39 2025 X-Original-To: freebsd-current@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 4ZgLsn33x4z5skTT for ; Sun, 20 Apr 2025 08:15:41 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZgLsn2RPvz3MF5; Sun, 20 Apr 2025 08:15:41 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745136941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6UBq60G6LNbMxOuE1vhvnkX3BB4Yz1YP7QzS/WmMP0w=; b=WwURT+I24YBL4R0WaYCBKa1Eu/2JA3cLbq2WC7NRlEKeQpZs6p55S6N2gI7GjJwhOsA1rm GCMIiPENy6BiGikX1ofb0Um4NnhloUgaVTt0UW4lj1tJpRYZ+5vMko4rDoFhm3kAZyPHgR Rf+Gb9xEx42zeMddkxWJnwMyEa0v0TkZCKfk307hgIKoXwpirgdLzEtvFex3SWxC7UoHZB 8dRJHTYjcyBJL0HEj/sieqGww6FD/kxmB7B8FPbnNKuTNmUoN1BR1A4IEvYHKG5HPhlciP ylo4eOdXg6tqMRdwk5C0C2iuI17jheAgMGBYgfrpMiXjXm3M6mVK9gk69tis0A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745136941; a=rsa-sha256; cv=none; b=YxcjvXyznEEVsRgEoX5U1+gAbKG26v+KcouWc6wfq9OHecb9ZO/BdkfNyWMKYyiIsLOps8 wy999Z+V/ZzvFPZqJQFBRiZOutvavMooqHI50HVKWaOd/fMppjWkPp43rxySh3kl9z8I3I 7PH1irEU5wb6092WWfrZoyHjcw/HFdTBM19R0cTZcVvZmzSr7nxa3Icc7i+RZtZ25dmRkc cM4NjMtOS4+Hn9TJAzAzd0sYatojIjjqtK7Oj4BF5CndK35+Xo4QSsOrrBFRAO07ybhmoa hqaTX8PiHoQT4IeQAbYkXRfFKxKsyse+jLvdpnAATCYls598JgqUjNORjVMlEQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745136941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6UBq60G6LNbMxOuE1vhvnkX3BB4Yz1YP7QzS/WmMP0w=; b=D6J231wrz9K74J0nk4JdZ3nGcx5lPD/gSX26l+e766bolhJ8Iz2eLrz6aJd5fdZc2OzbAA TIcEZ0A09vHFJCVx2XugexBQktSvi6OYAHhDuU7RoTHUUyWFyvLsUJSqE3XqBpsZ08INGI tBKaxrjvzC8qejtyGU0DRABgzNLrblgAbsEpaBqYzZoLPtBrzfnuZbOuT8nxyv+Npr6eBn /6n/ucQIhWDh9k/cEVbmdPa2QiOEjm3XvoURT8r7u1/di+Qj4bBc70FO2ILFU1DCWgU0eG lA+ovvK7zSddC5ZcR5H+JbR7qWUfouLdkitAtgVrpHTqax2jsvUkFVTZSYcB3A== Received: from ltc.des.dev (88-177-82-251.subs.proxad.net [88.177.82.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZgLsn19LhzxGx; Sun, 20 Apr 2025 08:15:41 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 2C71FF1959; Sun, 20 Apr 2025 10:15:39 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Chris Cc: Warner Losh , freebsd-current Subject: Re: New kernel =?utf-8?Q?doesn=E2=80=99t?= recognize ufs gpt root filesystem In-Reply-To: <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> (Chris's message of "Sat, 19 Apr 2025 22:23:10 -0700") References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sun, 20 Apr 2025 10:15:39 +0200 Message-ID: <86bjsr5jv8.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Chris writes: > Warner Losh writes: > > Maybe this is a custom kernel without the label code. > It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But > I'm using the same kernconf as before. Was label removed from generic > in the last 11 mos.? Please share: - The output of the `what` command on your old (working) kernel - The output of the `what` command on your new (failing) kernel - The kernel configuration file you used to build the new kernel - The contents of `/var/run/dmesg.boot` after booting the old kernel > > What does '?' at mountroot> prompt say? > nadda, nothing. That's hard to believe. Are there any error messages relating to nvme prior to the mountroot promopt? (if necessary, use Scroll Lock followed by Page Up / Page Down to scroll back on the console). > > Does one of those work if you add 'ufs:/dev/' to the > > front of each of the geoms listed? Most likely ada0p2 or nda0p2. > Indeed. It's nda0p2. But ufs:/dev/nda0p2 returns the same error 19. > I had to move kernel to kernel.new && kernel.old to kernel to get > here to write this response. You could have just selected kernel.old from the loader menu (press 'k' to cycle between available kernels) or prompt (`boot kernel.old`)... I would however advise you to copy kernel.old to kernel.works, as it will be permanently deleted the next time you install a new kernel (unless you use `make reinstallkernel` instead of `make installkernel`). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Sun Apr 20 19:19:45 2025 X-Original-To: freebsd-current@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 4ZgdcB215vz5tWZc for ; Sun, 20 Apr 2025 19:19:54 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zgdc959lrz3STB; Sun, 20 Apr 2025 19:19:53 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53KJJjoe029730; Sun, 20 Apr 2025 12:19:51 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1745176791; x=1745177391; r=y; bh=AA7+e35P7eAy4QDWBYsgVtF+qKfmy6pwY1+kaMyZvXc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=GxhrpbvKxnyKm1wrmEm9IHW/ndhsGBvK4sAzwvWjl38xYycGFRPN2Npn2L5mYcI7y 2n+paUArVLXJTxn1NuqE5rMNbwSafIW4XEpBCAv7RLqmARtp6fOjbzD6M33/YnBbix VwsLC/GKl/qpEWtbTeAmEUa2oFH3N6cXDIbog4gRWcNikSjDdr23xs6sooW0qv9tMH hQORdRVvIfkJE5FZaliLmclE8Zhutj83kqI9p9lKAnO+xch/zvfh7yU3PuMeaUR6Sj Nh779QJaC02syIgnO0ctIhjF1G1pOZbZwFJ5igsuID9pLTHLcJBmKBurSy2SzppNIs jsqi10525Tzlw== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Sun, 20 Apr 2025 12:19:45 -0700 From: Chris To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: Warner Losh , freebsd-current Subject: =?UTF-8?Q?Re=3A_New_kernel_doesn=E2=80=99t_recognize_ufs_gpt_roo?= =?UTF-8?Q?t_filesystem?= In-Reply-To: <86bjsr5jv8.fsf@ltc.des.dev> References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> <86bjsr5jv8.fsf@ltc.des.dev> User-Agent: UDNSMS/17.0 Message-ID: <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_a13dd1106c91928b52b86a2cb864da31" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4Zgdc959lrz3STB X-Spamd-Bar: ---- --=_a13dd1106c91928b52b86a2cb864da31 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-04-20 01:15, Dag-Erling Smørgrav wrote: > Chris writes: >> Warner Losh writes: >> > Maybe this is a custom kernel without the label code. >> It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But >> I'm using the same kernconf as before. Was label removed from generic >> in the last 11 mos.? Thanks for your reply! > > Please share: > > - The output of the `what` command on your old (working) kernel FreeBSD 15.0-CURRENT #1 main-n270118-94b09d388b81-dirty: Mon May 13 12:57:41 PDT 2024 > - The output of the `what` command on your new (failing) kernel FreeBSD 15.0-CURRENT #0 main-n276516-65d8491719bb: Sat Apr 19 17:41:06 PDT 2025 > - The kernel configuration file you used to build the new kernel https://bitpit.us/kern/LENOIP15ND-NEW here's the old kernconf: https://bitpit.us/kern/LENOIP15ND-OLD and here's a convenient diff of them: https://bitpit.us/kern/LENODIFF > - The contents of `/var/run/dmesg.boot` after booting the old kernel https://bitpit.us/kern/dmesg.boot > >> > What does '?' at mountroot> prompt say? >> nadda, nothing. > > That's hard to believe. Are there any error messages relating to nvme > prior to the mountroot promopt? (if necessary, use Scroll Lock followed > by Page Up / Page Down to scroll back on the console). No. Nothing apparent. gpart reports a bad label on the 4th slice (OpenBSD). But it's done so for as long as it's been there and that wouldn't prevent the freebsd slice from being seen. It's on 2. > >> > Does one of those work if you add 'ufs:/dev/' to the >> > front of each of the geoms listed? Most likely ada0p2 or nda0p2. >> Indeed. It's nda0p2. But ufs:/dev/nda0p2 returns the same error 19. >> I had to move kernel to kernel.new && kernel.old to kernel to get >> here to write this response. > > You could have just selected kernel.old from the loader menu (press 'k' > to cycle between available kernels) or prompt (`boot kernel.old`)... I did this for convenience. I knew I'd need to move things back before installing world. But as the (new) kern wouldn't boot the system... > > I would however advise you to copy kernel.old to kernel.works, as it > will be permanently deleted the next time you install a new kernel > (unless you use `make reinstallkernel` instead of `make installkernel`). Understood. That's good advice. Thanks. --Chris > > DES -- sent from hardware written from and running on FreeBSD --=_a13dd1106c91928b52b86a2cb864da31 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_a13dd1106c91928b52b86a2cb864da31--