From nobody Mon Nov 10 03:10: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 4d4ZS706hqz6GTjn for ; Mon, 10 Nov 2025 03:11:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 4d4ZS65WZgz3bxL for ; Mon, 10 Nov 2025 03:11:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=aQtG1Lrq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762744256; bh=AMvMoSej2H5a3u5TTsK1MUYiTVgpJy9koG1oTz4qfS0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=aQtG1LrqfWJHd0FkymgARJvC74Um9z/g3IgZWuS4+K/IvP1XQ9e7BGPePgult+aq5pMGs+zMS116MqpHTNbfkAGDnlf69gf94ZaMkEcxOcDe2AVEhz/12vf19SQzcPQJEnBQiQnbezfbAeRdVxVyXPFGC9Ltq9Su+SymAeLjQKsFNnKwHt1jmR2wBm/Vf8/yX4GZRWTq6SjPtEdms1F7QRhgqMqKGuGsekHVmEVyqBjawwHHkwBhqSUALX6agDcQ0sAbFsraBdx+K65EJfv19eVMCECloMipjz97ftUljeTM0KatO+eaRvCdvXV8cz7buEnTnlRgV6eBjy3O2Oe13w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762744256; bh=oJ1/qtjfUduVd1aoAjHWxN8Doj/Mtj+kBkfR9GYfMlM=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=gXgzgefMN4ygxqU1R/MWq3M/KfyyerMpIf+OzMBMBv1ff01u5VYjJqyYVAHy/2umv0yCF19NdJH4Q7rpRRkvoARUdYLs3HAwxXAJiXZamUtV0rsRekUISB1dExn/L5RB2m0MBF9BrejLfuRvpav1e7RcDRKFTV5wGPcMf2rWDqYSBR0+cKIl8pH0wV2Xh8B3J5JefLYZV6TOHVvnFSR9ItzC50um5VKjVQa3kMFzLDRxuaOcOp0Zk3CuAY2BqEWq1HJbLLwIq08acWqsaZzd+X9F0lGYOLSrnVGZ5K9/owXolpp/3C/Rzmgk+4+phcSBiALC4n0+hSKra85O9MrEmQ== X-YMail-OSG: dpt2tYgVM1kslY5p6e1W0vVfB8_98tw5778RGB4ws7..h3XKzWCCjZyUHPaZdx5 rdSBkoRLbZEjThShoq10GoyGn2vO8K.01y8YwvdzN6A.fap_aP7WDL2ZQiHZaiKNhbEJL0BWae1k JuDGi4j69fQ7MP_Xh_yItwcgvauLjUr2aSAJwQsDtepSVFZLOQQCQHcduxGszID6jIEM12lGKg4u 1U7GFBKjINjRteI_hK30Np4pbCosj4DLqIT.TMWCsERQPmXPDPopHnDVkAvzrAknpqVmtbs70E6t V1gfgFCzSBmTL3qYfgnoXrG9v1FcitWI8unZtkkyV1BTThIR7tSEYcSSZun.ohiL4_rrKnJ9zeVv 33OUQva7YPGbNy4Vln_ZJkUqDwd7FqL6gXfy2t4TUWwS5w3c.IFYq6g_F9jCHwVE_ChPB_.MYG6T AOxfD6HSUrV54KvSclfB_G6_N2xKPPrf9nwEaB2NJzwSSBm6XoiMKaRzsnmSRo.OVvEDEdcNxNpv h6lOVu5ieUz_rqmlg6HChj4aZQirf69jV8tkYXukVg.rdPD.jSeZMR60ZlWyjxysN.kdDycvUXso QEv0VRYQw4piwxPPltds_s6PR3tjSyQkwtY3_wMSIBGAjlmSyg_b.2lERhhcSwJoz87WfiHYCCeX pTNMdFuaIHhZTR8ZoMJLxJ.oZGaHvrzTKxiokVw57Ly8aCTpm8fIOq6qKLFvlJuY0gGFOJw0GVsE Ds.8pv0u4ZqqGr1VRfk_sOq6jGniHS83lpnSIQlwFebRnl9m89Oy54qDXUoOSFCopn3B5Yz4eNEm ASUWGya3UMBc4UOU2WiKgPBhcBVFSmy.H3r9b15RY1p0m4_VEimgGgvYHgJLKmHO7Zq07oq0FZ_q k3X7Ti2Olp9eckQekO45uZQ6Ud.5YIlnObnw8c_ckXw66xL3xpfi.GCY8_iZgMiAakJq25NDXpjj W73GSj39zzkHBKEIbCf.tJIgca.FCwFmQ2OILItNvFbmC.Vb_j7JcheiVm2TE4Fhekh5o6Vqs.kJ x4AtKf8oPbOm_iQvySDFvlzULYiQm6O64uaK.uvji0MUTHvBcIQHOjZl.WEocXfDLYdTN_NDLZaY WDhwKTmrTt99fS.1UGa8_29BU.w4RLxSUFM0VMDgkwBqu84OmxIqFbaF29RMZzxXR8WxSMpH9wxb q6dNBxk_aiUsFxMyvOdq1H03MT3y45IVAMym4lqzcmy_GRdV4Ml6Sx4wGHO_VghP6VW2DNxu8uKw O1BK2BTJnQhCbFnhBK2h9piul9PqaNXgaUSuTuLML3XLy7qU2bTBFyxNj3t.y_ej3yKLqhnW3kk9 3CpRpvkVATnhuzOSqp_fe6KtfmF_XjixiIbSEdP7DAg0N.pOzx820Y3dct2KKjOiASQiFrpme7J7 2H.wnBszZT6QyiShGgodHI7OSjEQKpydjpy8Z3InnIhSZsLqcqqXDKc7Lyuk5miHKG6MY5V858Zy l79WDq2fQiQCuXrOmutzE8pl0DRkRhDPVPOLMyHznc0mmoKyRbGkl4Wo6E.x1H_0A8FoeaAAEV3d dOIeO16Lk9gJC0edmJAKwYmzv68n9Q7uPyAmGd94nZP3Npf98ifdIeKLUMajipfneQYbKF.6yiuw QUNW928lRP1rXOVm35V6Dpy_tkr8pGlJMLFba1Vnse_InaZeBmKqlPtBxPU_zQjXqrHyC6kvvYD0 brrBzZ6g7qrnjTu0JW8fJ7zkfzviOukwc02hTcEA4ekBXJEfnVlI2ggaPi6XRntwFHi_NeCiQQO. fSdzqQx9lI_j8.HPnB7eEhL7KV23o2p7oQH5ztLzqifEY.y4WNDfUXjWbYNMSQbRldgl20xCeSI5 W7Jh_z8ow5qvlbw_EnUl1FL3rzlJXGh9qT0NPkJYk9ziMICqeB.oIT04l42hLLpW0V3O_1itAjVz W9FU.hv.4zt_aF.KSDUaASJl75gDKCMvxAkBde8vKJHcBMANje15IrVai6mxpjRVfVySG6SbigLW g.fbnZA5IoWJE4QbrPcwpFpHt2N6fX7GVmoaoI3mTXH8uHuP7nXEkPKqXnnEVV42ghJbNrsVtj6d EKmAdz.qvWss3TYPUpDNfsxXIRMGEAZzxwN87gRDfPpfmoDtjbMUdZGT0wzPkiygtEGNOKs0DvhV psePoU8JBCHKDis7sNN_Rz.I7mKolqmL11ZfetKzRt8tPf4MnRrsjG6q0RfsC5hCWgBK6qFqq8RV ZUaeXj8jIuMJ.SiiRs0j8AVMDYRiX8u_35ApCqC6_R4M5KvU15VExYwggXESZ_CXJuTq9xDDCs72 WzAvr X-Sonic-MF: X-Sonic-ID: 00d11ab4-255c-4e6c-aea0-7bdebf78a0ea Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 10 Nov 2025 03:10:56 +0000 Received: by hermes--production-gq1-86c5846576-hh7b7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c05b556a6cd481098bcdac592d41378f; Mon, 10 Nov 2025 03:10:52 +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.700.81\)) Subject: Re: Backout git revision 4179e6b78297369f [ finding drm-* pkg fallout logs ] Message-Id: <2068EA4D-8770-44F9-B0CE-1478A9E8D468@yahoo.com> Date: Sun, 9 Nov 2025 19:10:41 -0800 To: "Bjoern A. Zeeb" , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: <2068EA4D-8770-44F9-B0CE-1478A9E8D468.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.87 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.87)[-0.866]; 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]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4d4ZS65WZgz3bxL Bjoern A. Zeeb wrote on Date: Sun, 09 Nov 2025 16:56:28 UTC : > >. . . > > I followed-up on the PR but I have no clue where pkg-fallout stuff > for drm-kmod modules go -- do you have a link to them? Not that I am doing > drm work or ports but I'll be happy to look. One way of finding and looking at the logs of graphics/*drm-* failures (glob notation) is to use (involving regex notation instead): https://portsfallout.com/fallout?port=graphics/.*drm- The "report" buttons for build failures get to an extraction from the what log buttons provide. (The drm-510-kmod failures for 135arm64-* are for a different issue for what is currently shown.) The first failure of drm-515-kmod for this is reported as having UTC 2025-10-02 04:25 . (At this point the history of fallout logs goes back into 2025-Jul-04. So there is evidence that the errors are recent on that scale.) === Mark Millard marklmi at yahoo.com From nobody Mon Nov 10 08:15: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 4d4jCl3yJXz6GN5Z for ; Mon, 10 Nov 2025 08:15:47 +0000 (UTC) (envelope-from truckman@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d4jCl3QkPz4540; Mon, 10 Nov 2025 08:15:47 +0000 (UTC) (envelope-from truckman@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762762547; 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=C0x0i192eji2bNK2symwzhI5LRGB1wyHZYQRBBZe2yI=; b=nBk4UgwQdXVD/6vOg7qrxLxxGReNL8VWfDTKNQqv/dCiHGgnxy+90w1mS13I5rlDpORide MLi2niUwUJVBIim4zhe7rqqGrXtDsDgnOr6rfSR1Tz77PDXzGH6BTn6X1CTyKiAyeVPuWT +d3weAIyLxVhTYw35ICAAHzS7zrs48hwRIxUswsVMnpmbvTXm4qFHX1ThqwHUUoVrUMT4y wvxISKW6hnsCKbh6gP2QoPzf7YLLVxfVvdYEM7rjuczb/G401R6JoaK4UudSYy5jFhNaiz yBtCXHYI5ouhdZJA1KF3QqgBvEzWpSsZmTEWe69VIA3CZnU0Nl4VAfsTMpWEOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762762547; 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=C0x0i192eji2bNK2symwzhI5LRGB1wyHZYQRBBZe2yI=; b=jZy7y02ferd96exSarEXuaJ9gIwcvhD3Bycd0ruaqH2157sZ/YCvurbeIK8My9MMAx0UKo 6kHvzcrwMRn0i57JCpi4WJbuDUTP3XcF4bK0+Rp+4FdGt47T6CQjhJDEQYX+vqxXo1/mox miwRPvvrWnNcNU4ul0H0fBntqERkJlMOSqqROcuqN2O9mEyz03b/CC0GehAuWveOWIvS/F jaAx3HmypCqGqDesO+ffIiXdm31xLDqq3n26mg4Mo/Bc4G+gldc5YPyKScQWtox0m8kQMU 6UZI0fguI5IHcbpNcE4T0Ma6OzLgkP2BBzQG4+mGyoVwPX7jiyLxRGoXW7v0rw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762762547; a=rsa-sha256; cv=none; b=SAlpc2pgK8uUy7//0kiE+3B1FG7rdL896/5d0rX4flgOXx3QvNQtPlO+RaI1s+YLBpFCAQ 3N6OXZIBAILDdkk/0uhdusI+SbUwAUn1KYYWmA+Oy+9rlNEiSsIU6pLLbvKe5PAZkidb8a KJu0SyRGu+VUgaLrEHknmjaCILedsUH/oDQAArAA+9sRLgpE8Tfsb/e7oZUMHM54ODLHgV PreksbFtmugr2I6Cogp6DDzWZ5fFXya1l3U00EZYUudhW4FFxn25cjKJUu5NdTlTwxJZdY eWwkfrQROEx1jyWKOPbpeYiONxVDfnGDpEeODZdAAdwLwuYLJooovaXOXlI9EA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d4jCk5Bn6zlZq; Mon, 10 Nov 2025 08:15:46 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Mon, 10 Nov 2025 00:15:44 -0800 (PST) From: Don Lewis Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Rick Macklem cc: Ronald Klop , Peter 'PMc' Much , FreeBSD CURRENT In-Reply-To: Message-ID: References: <2100145914.14642.1762672441817@localhost> 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 Content-Disposition: INLINE On 9 Nov, Rick Macklem wrote: > On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop wrote: >> >> >> Van: Rick Macklem >> Datum: 9 november 2025 00:23 >> Aan: FreeBSD CURRENT >> CC: Peter 'PMc' Much >> Onderwerp: RFC: Should copy_file_range(2) return after a few seconds? >> >> Hi, >> >> Peter Much reported a problem on the freebsd-fs@ mailing >> list on Oct. 21 under the Subject: "Why does rangelock_enqueue() >> hang for hours?". >> >> The problem was that he had a copy_file_range(2) copying >> between a large NFS file and a local file that was taking 2hrs. >> While this copy_file_range(2) was in progress, it was holding >> a rangelock for the entire output file, causing another process >> trying to read the output file to hang, waiting for the rangelock. >> >> Since copy_file_range(2) is not any standard (just trying to >> emulate the Linux one), there is no definitive answer w.r.t. >> should it hold rangelocks. However, that is how it is currently >> coded and I, personally, think it is appropriate to do so. >> >> Having a copy_file_range(2) syscall take two hours is >> definitely an unusual case, but it does seem that it is >> excessive? >> >> Peter tried a quick patch I gave him that limited the >> copy_file_range(2) to 1sec and it fixed the problem >> he was observing. >> >> Which brings me to the question... >> Should copy_file_range(2) be time limited? >> And, if the answer to this is "yes", how long do >> you think the time limit should be? >> (1sec, 2-5sec or ??) >> >> Note that the longer you allow copy_file_range(2) >> to continue, the more efficient it will be. >> >> Thanks in advance for any comments, rick >> >> ________________________________ >> >> >> >> Why is this locking needed? >> AFAIK Unix has advisory locking, so if you read a file somebody else is = writing the result is your own problem. It is up to the applications to adh= ere to the locking. >> Is this a lock different than file locking from user space? > Yes. A rangelock is used for a byte range during a read(2) or > write(2) to ensure that they are serialized. This is a POSIX > requirement. (See this post by kib@ in the original email > discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-October/00= 4704.html) >=20 > Since there is no POSIX standard for copy_file_range(), it could > be argued that range locking isn't required for copy_file_range(), > but that makes it inconsistent with read(2)/write(2) behaviour. > (I, personally, am more comfortable with a return after N sec > than removing the range locking, but that's just my opinion.) >=20 > rick >=20 >> Why can=E2=80=99t this tail a file that is being written by copy_file_ra= nge if none of the applications request a lock? Since writes don't go backwards, it would seem to make sense to advance the start of the range lock as the copy proceeds. As long as the read position + length is before the write position, there is no reason to block the read. Running "cat outfile" would look a lot like tail -f because cat would only see the new data because it would temporarily block if it ever caught up with the copy. tail is a bit funky, though. If the size of the destination file is updated periodically during the copy, tail could return early with an earlier part of the file. If the size is updated immediately to the final size, then tail will wait for the copy to complete, but will output the true end of the file. What about backups? From nobody Mon Nov 10 08:58: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 4d4k945Tbzz6GQSl for ; Mon, 10 Nov 2025 08:58:32 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 4d4k940DVHz3CKR for ; Mon, 10 Nov 2025 08:58:32 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iitbombay.org header.s=google header.b=K62xd89D; dmarc=pass (policy=quarantine) header.from=iitbombay.org; spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2607:f8b0:4864:20::102b as permitted sender) smtp.mailfrom=bakul@iitbombay.org Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-3437ef3c9a4so93314a91.3 for ; Mon, 10 Nov 2025 00:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay.org; s=google; t=1762765109; x=1763369909; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1fGSm5tcZd22Nf+X2PXaEOlLHTqXgurgoWLhqLdnX/0=; b=K62xd89Dt0zb8Pk4OWzmODxO6FMOuUSUvKA4hV/28TPRahO8n2zDAlEOIXahOIB6Kw UIXcZS8sdwxC2spg6vPR5Yia2gMClwlV1z0uCQSw+EumvCPmMx3eInLWjmcTqfV31MwE +anBhHqO/vIZwfT/BPEPAyb/V7JwOqfttyBI0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762765109; x=1763369909; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1fGSm5tcZd22Nf+X2PXaEOlLHTqXgurgoWLhqLdnX/0=; b=R0f/1JTHYt+6AEDVO6FydQ2fGFWcmFMrXHzf9xqgOdBBgSQgWTZsPQ7ECBh3ZvmwDY zML1fkta0QEAUzedJFtHoZrZZyOJbiT2a5uSA607a0XXOibekJGKuiehqzTKxHD518ON TNJFbygbfv0BdOHnjBXMptl0aDw8SQJHJpdnH9bSBqV+uoE77F4It4KmBxJmbjOR48fK lJ5t6yZJvBvjPINr715R1U4cuAaAlqx51enQDW0EJA9AdyOVEnHTaDYS4dCpT+Rdn5U0 AbVuCz83OOzpiC98QARvOmeVau7B+c0OYYFhixs5jNjYtAW+bwR/Scjyuz2BfkitEYY8 yAXA== X-Forwarded-Encrypted: i=1; AJvYcCVdCDoGIDEJ5ypLwDX16CX+fa8d6DfdmFGWjL+Lu6qWYNNh4vAejHb/9mr7wSCqlDJKY8ZF8RTBPdcPRLUgaRU=@freebsd.org X-Gm-Message-State: AOJu0YwI0I1xllob8brc01lIYSF4yBhuSAwcueJo6NWvkE9fSTNNsDYU j948puR8KBot4qA+JPcOK6NOtdAa81K6OncTFFXpNi+HKbzx6iMIVRo6iajuseRk0w== X-Gm-Gg: ASbGnctIu+EHSiA8OxokZZywVhRGlwFBJ+G6ba7EMi7b5XKUfH46iJ8MUyDhQgZr/Lo w5AMyYlx6AsM8QEUBLqqw29YkhCJ/uXfJ6rVXQcX2kDsSvthM8VFXUmYSkcAghU7n5zFfj8M6tB /+VcbaHcBs1FDTyelPkM8rRkRn+EAurJav5FFk4ENgSX0dtOFH5OC6uoFtx1r3cYdWY3GO6bSCl kwhK+gC1WnJEP9XN2HhbcgpLIK61RDZB947qeUG8CmxOYdS3JGlVLFLSAjJtoDa5eSN9q9u/wpm yA/mirfTZGUwYXszUzhLQMeuO9gLR5+287lA71ze7SA++HXkYc3polVsWnsa1svM7DkOauT7UcF U57JJtZagVsk4UmaB5cvTT4nbr9pOGt9PX2809HFkcu7njUcLaVUq0WH780PL0Azowuw7ZU+miR XnS4fcaNFhd+VLNYo9y+f0htc2Xohxjl0r+fRe1rrHtKGW6bYInpqPPGcYtkiWfDf/eWIlhAFeL zMYp7pzpgfbfRI/ X-Google-Smtp-Source: AGHT+IEQGa1V/2Ebd1ExBsdQrVrA9ZtxQuhoqUirKiUlF/UolHiheZsSM1QK+v/oRc4vQc0ybsopGA== X-Received: by 2002:a17:90b:1b44:b0:341:88bc:7a54 with SMTP id 98e67ed59e1d1-3436ccf5f21mr5121905a91.7.1762765109571; Mon, 10 Nov 2025 00:58:29 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-ba8ffe36bbasm11830280a12.18.2025.11.10.00.58.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Nov 2025 00:58:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 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 \(3864.200.81.1.6\)) Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? From: Bakul Shah In-Reply-To: Date: Mon, 10 Nov 2025 00:58:17 -0800 Cc: Ronald Klop , Peter 'PMc' Much , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: References: <2100145914.14642.1762672441817@localhost> To: Rick Macklem X-Mailer: Apple Mail (2.3864.200.81.1.6) X-Spamd-Bar: / X-Spamd-Result: default: False [-1.00 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[iitbombay.org,quarantine]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[iitbombay.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[iitbombay.org:+]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEFALL_USER(0.00)[bakul]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102b:from] X-Rspamd-Queue-Id: 4d4k940DVHz3CKR On Nov 9, 2025, at 12:52=E2=80=AFAM, Rick Macklem = wrote: >=20 > On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop = wrote: >>=20 >> Why is this locking needed? >> AFAIK Unix has advisory locking, so if you read a file somebody else = is writing the result is your own problem. It is up to the applications = to adhere to the locking. >> Is this a lock different than file locking from user space? > Yes. A rangelock is used for a byte range during a read(2) or > write(2) to ensure that they are serialized. This is a POSIX > requirement. (See this post by kib@ in the original email > discussion. = https://lists.freebsd.org/archives/freebsd-fs/2025-October/004704.html) >=20 > Since there is no POSIX standard for copy_file_range(), it could > be argued that range locking isn't required for copy_file_range(), > but that makes it inconsistent with read(2)/write(2) behaviour. > (I, personally, am more comfortable with a return after N sec > than removing the range locking, but that's just my opinion.) Traditionally reads/writes on Unix were atomic but that is not the case for NFS, right? That is, while I am reading a file over NFS someone else can modify it from another host (if they have write permission). That is, AFAIK, the POSIX atomicity requirement for ead / write is broken by NFS except for another reader/writer on the same host. Another issue is that a kernel lock that is held for a very very long time is asking for trouble. Ideally one spends as little time as possible in the supervisor state and any optimization hacks that push logic into the kernel should strive to not hold locks for very long so that things don't grind to a complete halt. That is, copy_file_range() use in cat(1) seems excessive. The only reason for its use seems to be for improving performance. Why not break it up in smaller chunks? That way you still get the benefit of reducing syscall overhead (which pales in comparision to any network reads in any case) + the same skipping over holes. Small reads/wries is what we did before this syscall raised its head!= From nobody Mon Nov 10 09:02:54 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 4d4kGV2qB4z6GQXY for ; Mon, 10 Nov 2025 09:03:14 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 4d4kGV0jNxz3DMg for ; Mon, 10 Nov 2025 09:03:14 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-6406f3dcc66so4583460a12.3 for ; Mon, 10 Nov 2025 01:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762765388; x=1763370188; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=E8xUm4MJf/OxHgElEb1Ll1LIdOwgPP+D3LYVta5sJ2M=; b=b7A0JUG3qHyrwZmhl2ocStJfrmofb2HwO6H6Oc9UPvcg+4fawDhqsfUBtQRLkwhtKm iS8wIvOVaFH1fxMM8eCY8goHlbuJuTtR7A1cRLvx/RgD8U2Z4EWvkiMFXBTel1FoDzqA pKr2PLZakrV0nFQfdjsqM1WQDSHpGUWgZeEsuMqsDpWCj2v6EZM9I/+LW0zKGtD2gSTK 9tlmf3dpCsdlrsq4Zl9S8iWQfq3GgUy3u5gbcnrJVEcq1wxXjIDT/+9ehmmksuevvzu+ H0q+wKBI2f7lmEe7QxtLimGCa3fVNRxh2vliaYUg2SmpQImtZUHOdq4qUnuOtWahnAVZ XDEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762765388; x=1763370188; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=E8xUm4MJf/OxHgElEb1Ll1LIdOwgPP+D3LYVta5sJ2M=; b=VVPqWO1iZ1TLBWxkPrAXtstUP3HCH+nQQ80txpdgmpStg9Qy+A+jp9Bmb4CpF5/VVC bDFY0HzAXcVsIOnpgm6MW4YkuWeeabo2orcjee4nwWOgZywzKk8m4kEGrkBtSjEyMnKs +RpRfBcSJ7nt1JOmiNYgRugxLPAx6BRxFp9HiMeZ/FqJvfroeO4Bx2leFS4xWfquaRzE LB6OQbexpN3mlUF5aqgVc5l5rQRU396ybV4Xnb2y8ruluqSYZ3EstJkAKpHW5RTKvFu+ CI7iDD2csWr+c4qZ/NFIc0H0rSEETNcKIck2q30xykxWXdNpWQhIrA4hr8IYakuGn2IW JPGA== X-Forwarded-Encrypted: i=1; AJvYcCWGtPlhQpeeqFOxMOxBcLYVi9byZpZhZGQwUl2vPvogvn2TPYA00ejuNY/7uz6fPBzXLkiWn1dt2kPTlU+/+7E=@freebsd.org X-Gm-Message-State: AOJu0YxRBQLBY3a4lnY6uF+IBflnymDN91D3ZEzAGbiLiamKF5fWyj3f KC07KNC44bvqLKeS3ySu4ZwsTkohJDznkB1VquNV9S8iUSPPzGEqAOTSVsuMoz37iPxEReb3cDC bZYWmjJYZTZFXVeRQ4Bt6Pq06EOsqP56QiJg= X-Gm-Gg: ASbGnctSVOmP3i0n7rOTfdE8PksNvdeebC9UcyiQiiO3IL2YUGFr2yKkHBufPn+f00S /rNzIO+rW2jnJFyq0mw3lTFbQAZwFYMut9wbg1ls9T6B41fptup8L5AeKmmzJkauyntbzyNqrki 6jyXUBv75lTLQSIAbEB1TlofUw5Rg3XTE6jIJG1jIC72QzQ8s+jdXtkEjuHl4EPUOYHTsM0s/FB Jc8yywe5ZhLiQ1pOdAEr9AeL03q3zo/x7WHTFUcoMlTVw1t/wTtawlx9EKSfQ== X-Google-Smtp-Source: AGHT+IGmbyFvnlf9h9BtbcH3XcE3gRlTZwt7T7bCHtu3ztKTiosETnMm4aoQQaJE6n1Lrpn2+KhFeKullFyy4rCcxtc= X-Received: by 2002:a05:6402:2106:b0:640:a26e:3d86 with SMTP id 4fb4d7f45d1cf-6415dc2e310mr6355867a12.1.1762765387387; Mon, 10 Nov 2025 01:03:07 -0800 (PST) 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: <2100145914.14642.1762672441817@localhost> In-Reply-To: From: Rick Macklem Date: Mon, 10 Nov 2025 01:02:54 -0800 X-Gm-Features: AWmQ_bkM0dsJOzozUht4QwDnjCPIb3php7jKddb9bjwnL-xg6k49rxEz5ujEu8E Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Don Lewis Cc: Ronald Klop , "Peter 'PMc' Much" , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d4kGV0jNxz3DMg On Mon, Nov 10, 2025 at 12:15=E2=80=AFAM Don Lewis w= rote: > > On 9 Nov, Rick Macklem wrote: > > On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop wrote: > >> > >> > >> Van: Rick Macklem > >> Datum: 9 november 2025 00:23 > >> Aan: FreeBSD CURRENT > >> CC: Peter 'PMc' Much > >> Onderwerp: RFC: Should copy_file_range(2) return after a few seconds? > >> > >> Hi, > >> > >> Peter Much reported a problem on the freebsd-fs@ mailing > >> list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > >> hang for hours?". > >> > >> The problem was that he had a copy_file_range(2) copying > >> between a large NFS file and a local file that was taking 2hrs. > >> While this copy_file_range(2) was in progress, it was holding > >> a rangelock for the entire output file, causing another process > >> trying to read the output file to hang, waiting for the rangelock. > >> > >> Since copy_file_range(2) is not any standard (just trying to > >> emulate the Linux one), there is no definitive answer w.r.t. > >> should it hold rangelocks. However, that is how it is currently > >> coded and I, personally, think it is appropriate to do so. > >> > >> Having a copy_file_range(2) syscall take two hours is > >> definitely an unusual case, but it does seem that it is > >> excessive? > >> > >> Peter tried a quick patch I gave him that limited the > >> copy_file_range(2) to 1sec and it fixed the problem > >> he was observing. > >> > >> Which brings me to the question... > >> Should copy_file_range(2) be time limited? > >> And, if the answer to this is "yes", how long do > >> you think the time limit should be? > >> (1sec, 2-5sec or ??) > >> > >> Note that the longer you allow copy_file_range(2) > >> to continue, the more efficient it will be. > >> > >> Thanks in advance for any comments, rick > >> > >> ________________________________ > >> > >> > >> > >> Why is this locking needed? > >> AFAIK Unix has advisory locking, so if you read a file somebody else i= s writing the result is your own problem. It is up to the applications to a= dhere to the locking. > >> Is this a lock different than file locking from user space? > > Yes. A rangelock is used for a byte range during a read(2) or > > write(2) to ensure that they are serialized. This is a POSIX > > requirement. (See this post by kib@ in the original email > > discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-October/= 004704.html) > > > > Since there is no POSIX standard for copy_file_range(), it could > > be argued that range locking isn't required for copy_file_range(), > > but that makes it inconsistent with read(2)/write(2) behaviour. > > (I, personally, am more comfortable with a return after N sec > > than removing the range locking, but that's just my opinion.) > > > > rick > > > >> Why can=E2=80=99t this tail a file that is being written by copy_file_= range if none of the applications request a lock? > > Since writes don't go backwards, it would seem to make sense to advance > the start of the range lock as the copy proceeds. The current code does the rangelock above the VOP layer and, for ZFS, if block cloning is enabled, the entire copy happens all at once and fairly quickly (it's copy on write as I understand it). I can't recall for certain, but I think the rangelock must be acquired before the vnode lock(s), so I don't think moving it to below the VOP layer is practical? rick > As long as the read > position + length is before the write position, there is no reason to > block the read. Running "cat outfile" would look a lot like tail -f > because cat would only see the new data because it would temporarily > block if it ever caught up with the copy. > > tail is a bit funky, though. If the size of the destination file is > updated periodically during the copy, tail could return early with an > earlier part of the file. If the size is updated immediately to the > final size, then tail will wait for the copy to complete, but will > output the true end of the file. > > What about backups? From nobody Mon Nov 10 09:09: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 4d4kQC5Bh8z6GRJ7 for ; Mon, 10 Nov 2025 09:09:55 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4d4kQC3GPsz3Fdc for ; Mon, 10 Nov 2025 09:09:55 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-6407e617ad4so4721478a12.0 for ; Mon, 10 Nov 2025 01:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762765789; x=1763370589; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=veS2wPnau9mVMVxBqtJOO5P4EMCPClMkopYbDXqxxpM=; b=fUj2JHtr4T9tZKLSmg5CrUUIjahelDUttraYFQq99w7PrJ3scLG4Rp013FELEW7W12 qtHEfVjxYeyievOb5cfxZ0WFHLrW9OTOgI7u5DzQzN4FuG99ckuyrZtg3FFlQJe99mRc B9aDQpjklxerKQlPDyA0zRhON2dlYJ59vp5jCw/KA3P5Kcniv/jNrBdvAQFLqV64o87u E08+xOkVByY0BZLRhn9dQsNR/7vI9+ads3lo3LGR7Sx8WqjBkXtWqNCLVM6QaOKgbTd9 E8UBTpau/tva62sqrZ08w1A8+ZDyuFN2jmATOTtoxzQKFFhJ/Hd9tcoAaUUPL9nahyV9 CHpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762765789; x=1763370589; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=veS2wPnau9mVMVxBqtJOO5P4EMCPClMkopYbDXqxxpM=; b=WYLoZyHjq7b1z/6kJW3S/PRaHlcZYMV/H8zq8Zb8HbbrNd30mx9c/kz7X+gGlS4Bms q0aLEtd+jIwb1I5oO31OlIfRvssea26/lL8RU4IT8+yvpG0lUxTnGop0LWcUcmOCF5wx +JEy09g0fb9xobOFlY9sMYM53AbKPExEB6afNn+YfI1IyzEk4sBHsaWXTogLvqbLYQCB ehgy3MSMl7ZI5vTmlnOMTqJDWbwPaBaUF3H4dOteEvWQBme0z/1HuiLwpMn0cK3TJUOy yVk3FRboieIpcWlD0lcWSM5n1L8OMzqWGBKes2zQZ6HGZSxXwhI2w92QGAtRCJRyGGiW VlqQ== X-Forwarded-Encrypted: i=1; AJvYcCX8QOJxNzZmuSnLpIpOG5uEsDw4QKdSSdq92+AZy9TdSKJhKeUgpo2oR61Wa2mXNLUlMw6NLYDvSNoLsGHeUz8=@freebsd.org X-Gm-Message-State: AOJu0YwB1AgyGtDkXGhtkg00sU2s5Vg2YGsxXugikqaXkDjGkxJrlTq1 KfsP/3mDNnt7m78LJiaEaFQOm/j0SYL1uw+P6DAfVz4fVLZoqLJs3DauKYOlu1gjkuia5UTjzjV 5SL1EqVCfqM5seKZKa+FkDhVk73nJ1g== X-Gm-Gg: ASbGncsAUcjxUU4sgDApbzJqM4a0tHteeUqyibrqvDr3dFi+8NvI2m2wuzCRxh43q30 NYQg1dqvQUgbQZur+ZMOe20oZUudOz62vAW6jHhtPfs2Ei0+TNAR3OBHTJkUsWum6k7/rMTmSKy 1/563kohRe8mT8DmTfuk1YeVW9/WgaQ1brt4Sec1LJSlheCPkUDCdQzxwph8bEElOHKRCBJp57O KkqsZnUw0V4ptkUzDVR73V8RI0zEimk4Ah/TF4KgHWpeTl0m7g5zgn9TxeAWfO67Y2XbSwo X-Google-Smtp-Source: AGHT+IEIRZE/ODNv5WuCAwnTTj0xg9BbnvrIYDAWeK7WODV76GY853lHfslRMAlTYi+GnhZXGR//XGi8r6Dela1W93o= X-Received: by 2002:a05:6402:5215:b0:640:9bed:85a5 with SMTP id 4fb4d7f45d1cf-64159e51fd0mr6911893a12.8.1762765788911; Mon, 10 Nov 2025 01:09:48 -0800 (PST) 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: <2100145914.14642.1762672441817@localhost> In-Reply-To: From: Rick Macklem Date: Mon, 10 Nov 2025 01:09:36 -0800 X-Gm-Features: AWmQ_bkveSo-IuZxvtJkUBKuWGBkLgTegrU30TlLjOYLSAXCq2HJ0pNQWtEGcKg Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Bakul Shah Cc: Ronald Klop , "Peter 'PMc' Much" , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d4kQC3GPsz3Fdc On Mon, Nov 10, 2025 at 12:58=E2=80=AFAM Bakul Shah w= rote: > > On Nov 9, 2025, at 12:52=E2=80=AFAM, Rick Macklem wrote: > > > > On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop wrote: > >> > >> Why is this locking needed? > >> AFAIK Unix has advisory locking, so if you read a file somebody else i= s writing the result is your own problem. It is up to the applications to a= dhere to the locking. > >> Is this a lock different than file locking from user space? > > Yes. A rangelock is used for a byte range during a read(2) or > > write(2) to ensure that they are serialized. This is a POSIX > > requirement. (See this post by kib@ in the original email > > discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-October/= 004704.html) > > > > Since there is no POSIX standard for copy_file_range(), it could > > be argued that range locking isn't required for copy_file_range(), > > but that makes it inconsistent with read(2)/write(2) behaviour. > > (I, personally, am more comfortable with a return after N sec > > than removing the range locking, but that's just my opinion.) > > Traditionally reads/writes on Unix were atomic but that is not the > case for NFS, right? That is, while I am reading a file over NFS > someone else can modify it from another host (if they have write > permission). That is, AFAIK, the POSIX atomicity requirement for > ead / write is broken by NFS except for another reader/writer on > the same host. Yes. NFS is not a POSIX compliant file system (and cannot be, given various aspects of the protocol). The client can only attempt to approximate POSIX semantics. > > Another issue is that a kernel lock that is held for a very very > long time is asking for trouble. Ideally one spends as little time > as possible in the supervisor state and any optimization hacks > that push logic into the kernel should strive to not hold locks > for very long so that things don't grind to a complete halt. > > That is, copy_file_range() use in cat(1) seems excessive. The only > reason for its use seems to be for improving performance. Why not > break it up in smaller chunks? As I noted, for ZFS with block cloning enabled (now the default), the entire copy happens quickly no matter how large the file, since it does a copy on write. To break it up into smaller chunks defeats a lot of this, although it still might be able to do block cloing so long as the offsets and lengths are exact multiples of the recordsize (default of 128K these days, but can vary per file, so an application cannot easily know what the correct read/write size is to make it work). I did not do the "cat" commit, but I think it is a good idea, rick > That way you still get the benefit > of reducing syscall overhead (which pales in comparision to any > network reads in any case) + the same skipping over holes. Small > reads/wries is what we did before this syscall raised its head! From nobody Mon Nov 10 10:10:05 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 4d4lm3258Dz6GVtw for ; Mon, 10 Nov 2025 10:10:27 +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 4d4lm23v4kz3PMr for ; Mon, 10 Nov 2025 10:10:26 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-64162c04f90so3065148a12.0 for ; Mon, 10 Nov 2025 02:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762769419; x=1763374219; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=J5GjgYfHNC0ojz9wHIDhEizxht026DK3K0m5LYqiVWw=; b=aEPLLJbytVK+oweopAN8WX3SWk4U/EoVrmH7fpiFqPPZ2ji7IsOOAZ1XHZ3/i6xMLC uv90Tw1wsBWu5+RCCTq10eWRAv9Iky7IcFRv3GY0iXI4n1PHNzXQ4mmqMxXyQOrRwVIY kXZLniSSM/apuvMsCmtkYFE/j398DtZsnxv8oE0rUAbSTMgOI774dVPhH4VrwsUeNxxu yOCgGvawlC5Y94c99q0hPnBsc7qN5u1OACtOpABulWE73n6wWFeD87HlljpzjBC+/OGf g3JRJiMEyLoJy8gnGCUtndB/9lCGFPWMGQtg4+uzM0UD4M8bFkIbL13Kwj/BCxx7SVwZ u6MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762769419; x=1763374219; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=J5GjgYfHNC0ojz9wHIDhEizxht026DK3K0m5LYqiVWw=; b=uztGNEHoYTL4RtNZYhX9JljPyC12YKX5ID/PRFJYrbosWYQ8njREM6XyFL5PffiGPZ 8dJw3FVj6M4btr7C8YDvrfWvryZmcJfGODCCLBgXlTmk2BKsR8tuCnqW0iRexKX3W7jM PmSAkbgY3mDzKOsew14pLJnsBBKw4a63r+Xb+O33JxywfJ4YeUJ570kgorMNdrkqyKe/ cyEUu3qj2hOLWrIr/DA864Hlu/bQKFysK6K9iNR1aw1DAMnuRp5uGt9D8ypYLa6TpTGP 60Ysf+JR098qZlg2MxoKyvUQoCpTamoLSCsKUO9vs45vN3X0f6S/yQJ+TF0QPwO3uSJX 5wdg== X-Forwarded-Encrypted: i=1; AJvYcCWg6dpoT/83QT2kof819Y4Yu61/kGUWDNU5fZDhn02OkmLEx9TUsTUCIGi+WBWR0HprWx3QTVwNQVm0yiq5JFM=@freebsd.org X-Gm-Message-State: AOJu0YzomFNkNPMcmbNhnk07a+4yZ9g6Gs8N/W+oRrsCn+/ovOzcY4Zu tfpxeH7CX6SUb1j1sx/RsY/b9h6xlH/QQl/Xq7SA5CIKIhRZYeU1tZFQc0vdW8gr7MxMFdSoUSn 0vHdxkTT/AkhiAr4dVoPY0csx7m326Q== X-Gm-Gg: ASbGnctM1w9x0gvUjlXADC++zkACN/dX2Fush2yk/eZD8Nr7MrKGS1BXbLS56ct4xFD nXlgQ3eGbZ3FAuZ8ZnLkLS0Fkl13VQnZkZDVK7okm0vdBVqEOxxWMrrVahmsWEccw1HLM5TIcUC epgH/NIVlyy7PfboVnG4TOIprpeiD9Vza8n3lUlN2pMbPJaxBIhwiOLn6HXkwGNpiOYTJXM99cO VDQXK2wnxA9cL6suAqa9rCp722B9sXeZu+8uIfzcqZCK6dN8ma09mJiF1E4bw== X-Google-Smtp-Source: AGHT+IEmdblHsR452LP/g4dHI8rKfA68IzxFXmA6UdhwdYYIXF79oeBQVdfYBiXaiGha6e1/jYaqqXirDmo6peFN0xM= X-Received: by 2002:a05:6402:4559:b0:640:9db5:ba2f with SMTP id 4fb4d7f45d1cf-6415e82b1f4mr5746200a12.30.1762769418647; Mon, 10 Nov 2025 02:10:18 -0800 (PST) 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: <2100145914.14642.1762672441817@localhost> In-Reply-To: From: Rick Macklem Date: Mon, 10 Nov 2025 02:10:05 -0800 X-Gm-Features: AWmQ_bnUSKrRWtlLO0kfFsWhrGT-_79JiEOofq7dejWuOzrVcWUcocHyZ1ZkMY8 Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Bakul Shah Cc: Ronald Klop , "Peter 'PMc' Much" , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d4lm23v4kz3PMr On Mon, Nov 10, 2025 at 12:58=E2=80=AFAM Bakul Shah w= rote: > > On Nov 9, 2025, at 12:52=E2=80=AFAM, Rick Macklem wrote: > > > > On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop wrote: > >> > >> Why is this locking needed? > >> AFAIK Unix has advisory locking, so if you read a file somebody else i= s writing the result is your own problem. It is up to the applications to a= dhere to the locking. > >> Is this a lock different than file locking from user space? > > Yes. A rangelock is used for a byte range during a read(2) or > > write(2) to ensure that they are serialized. This is a POSIX > > requirement. (See this post by kib@ in the original email > > discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-October/= 004704.html) > > > > Since there is no POSIX standard for copy_file_range(), it could > > be argued that range locking isn't required for copy_file_range(), > > but that makes it inconsistent with read(2)/write(2) behaviour. > > (I, personally, am more comfortable with a return after N sec > > than removing the range locking, but that's just my opinion.) > > Traditionally reads/writes on Unix were atomic but that is not the > case for NFS, right? That is, while I am reading a file over NFS > someone else can modify it from another host (if they have write > permission). That is, AFAIK, the POSIX atomicity requirement for > ead / write is broken by NFS except for another reader/writer on > the same host. > > Another issue is that a kernel lock that is held for a very very > long time is asking for trouble. Ideally one spends as little time > as possible in the supervisor state and any optimization hacks > that push logic into the kernel should strive to not hold locks > for very long so that things don't grind to a complete halt. > > That is, copy_file_range() use in cat(1) seems excessive. The only > reason for its use seems to be for improving performance. Why not > break it up in smaller chunks? Btw, the time limit I proposed does break it up into smaller chunks. The difference is that it specifies a chunk size that can be copied in K seconds instead of a chunk size of N Kbytes. (The problem with using N Kbytes is there is no way to know what N should be.) rick > That way you still get the benefit > of reducing syscall overhead (which pales in comparision to any > network reads in any case) + the same skipping over holes. Small > reads/wries is what we did before this syscall raised its head! From nobody Mon Nov 10 10:49:49 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 4d4mdy1S3cz6GY4B; Mon, 10 Nov 2025 10:50:14 +0000 (UTC) (envelope-from ivy@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d4mdy0xFLz3SV2; Mon, 10 Nov 2025 10:50:14 +0000 (UTC) (envelope-from ivy@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762771814; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=7WFIDfyVViVID7fn+IVAu6svFA7MB1KD3tsRENjz9EU=; b=QaaRHkS17t02rvK+4OZVmfEsfZ05+oSN2fNk8Q20rdA9giPPO2kndm8DmSwo6TcRI2qCzc 63jGvnXoatrHfDE48YNjngPVQPGkkUMJrOUqPtasaS7u7JU2rjy05JJ65vQuT1f7UcboU6 tfs4HW+BZ+JwMprcVP+RggNhmWP8QznR7tqGZS2lj3wqX7OZmpEMZYrTmfdVd1KpUbEU9J MZWsk3bcU5rHJvPKrVkc0hsH3eHiGuQNjrgNYFGogrGhKSnS8YxTZwzvluDWmB9Tuq/ZMA DLU2/GWZeHzcNnPxSlbSX5iz5jl1zHRKGUHtriD5hD/VaX/YqcbSuVUWi8azNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762771814; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=7WFIDfyVViVID7fn+IVAu6svFA7MB1KD3tsRENjz9EU=; b=gG0ODNJe/q/UCpqSy3uCugqV78IQwB+mfjk7sb8BmR3n5dWsISpyBknPttsn5mz7FEtNGN PZWabAARESgxNCv/H/R/I7HT20v3exaJapPzq6ubcOyilsQV5NATCYMOJZaV7LTYUfZWFp tVl7MAf3ChB4wzZCXHwicOmTFQP7pDDv6lqKr8CBBSbT18VuLR5jwxt3rjPf27XnFgBeFt oSsyQrLXr1vXbiAxIoC67bugpXhUy+jzZdg0DBLgAvh2xMfa9maxHTp1rvVmH+jjLhZXRI B5rw2SX465Pf5FwzQG/eRVJJm3qPfc9eOPABUvtOb3bIMzH6uWvbP4Qy/iNJsA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762771814; a=rsa-sha256; cv=none; b=Jb0HkRVdoEyPcZizc0J03O7+D/k+7RB9BLI399cdI2M9Cn7V4quz0MFGI+1J+E2pL+UF+b PhdFZJ3sp6+kCx21tuai8OvgRkpbDo0EYmsiKATfZeVrnFTKsu9FApTkXEpAAz3h0Wz/q9 DxgFuNPmRwXsri0msdQvTQI1bERu73/pzYXr1KirjJye4DylJCI7VcaWIlneW0g6fYlSMz Q64DlMepp2MmnHyecjwrR7Ff+wM+lY7UlNKRVMdn12NXoPqcFiL/TuPw++cLuPC8u07tz2 rWnaS/FrqYk0D09nbcsN/CXkWMSPGI+tSt9VpPmVYmIHl3ct9Eb9HxLxYo60Lw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from amaryllis.le-fay.org (amaryllis.le-fay.org [IPv6:2a00:1098:6b:400::9]) (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: ivy/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d4mdx50yhznV9; Mon, 10 Nov 2025 10:50:13 +0000 (UTC) (envelope-from ivy@freebsd.org) Date: Mon, 10 Nov 2025 10:49:49 +0000 From: Lexi Winter To: current@freebsd.org, pkgbase@freebsd.org Subject: HEADS UP (16.0 pkgbase): new package for PAM Message-ID: Mail-Followup-To: current@freebsd.org, pkgbase@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="zcr7DNOMo9lSiBp/" Content-Disposition: inline --zcr7DNOMo9lSiBp/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline if you don't use pkgbase, you can ignore this mail. hello, i am about to commit a change to main (16.0) which adds a new package for OpenPAM. there are two notable packages in this change: * FreeBSD-pam-lib contains libpam, which is used by applications that want to authenticate users (e.g. login(1) or sshd(8)), and will be installed automatically via shlib deps in most cases. * FreeBSD-pam contains the PAM modules (e.g., pam_unix.so), which are required for PAM user authentication to work; this package will *not* be installed via shlib deps. FreeBSD-pam will be automatically installed if the minimal(-jail) set is installed, or if the optional or base sets are installed, since those depend on minimal. if you don't have any of those sets installed, and you need user authentication, you MUST install the FreeBSD-pam package when updating past this change or you will no longer be able to log in. (if you don't have set-minimal(-jail) installed, i recommend installing it since essential system components will always be part of the minimal set, but this isn't a requirement if you prefer to install new packages manually.) this change will not be MFC'd to stable/15. --zcr7DNOMo9lSiBp/ Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaRHDSgAKCRD1nT63mIK/ YDyLAQDt3B21KeQelhpTAgvNk13MQZehGj/izYeUqXFHpLPU3wD/b84w4JwNQESO NnAltjruwAR4xHFuabRN0Grb5+MJTQc= =SJhJ -----END PGP SIGNATURE----- --zcr7DNOMo9lSiBp/-- From nobody Mon Nov 10 22:22: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 4d540M2zGGz63YBT for ; Mon, 10 Nov 2025 22:22:11 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with SMTP id 4d540K1yr8z3sdV for ; Mon, 10 Nov 2025 22:22:09 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=tarsnap.com; spf=pass (mx1.freebsd.org: domain of gperciva@tarsnap.com designates 54.86.246.204 as permitted sender) smtp.mailfrom=gperciva@tarsnap.com Received: (qmail 36403 invoked from network); 10 Nov 2025 22:22:08 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by mail.tarsnap.com with SMTP; 10 Nov 2025 22:22:08 -0000 Date: Mon, 10 Nov 2025 14:22:29 -0800 From: Graham Percival To: freebsd-current@freebsd.org, freebsd-git-weekly@tarsnap.com Cc: Colin Percival Subject: FreeBSD Git Weekly 2025-11-03 to 2025-11-09 Message-ID: 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 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.66 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; DMARC_POLICY_ALLOW(-0.50)[tarsnap.com,none]; R_SPF_ALLOW(-0.20)[+ip4:54.86.246.204/32]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; ASN(0.00)[asn:14618, ipnet:54.86.0.0/16, country:US]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[54.86.246.204:from]; R_DKIM_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4d540K1yr8z3sdV Hi all, I'm happy to announce FreeBSD git weekly for 2025-11-03 -- 2025-11-09: https://freebsd-git-weekly.tarsnap.net/2025-11-03.html It's a list of the 108 commits in that week, split into categories. Highlighted commits: - UPDATING: mention pf's nat64 support "Highlighted" commits are selected automatically if a commit modifies UPDATING, or if the commit message contains a "Relnotes:" line. If you think that another commit should be highlighted, let me know and I'm happy to make it so. To see all reports: https://freebsd-git-weekly.tarsnap.net/ This work is funded by cperciva@ and Tarsnap Backup Inc. Cheers, - Graham Percival From nobody Mon Nov 10 23:29: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 4d55Tq1bZFz63dk3; Mon, 10 Nov 2025 23:29:19 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-a4-smtp.messagingengine.com (fhigh-a4-smtp.messagingengine.com [103.168.172.155]) (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 4d55Tp0qSBz42XL; Mon, 10 Nov 2025 23:29:18 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b="gylvvv/5"; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="Z qCnOIv"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.155 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.phl.internal (Postfix) with ESMTP id 821FA1400210; Mon, 10 Nov 2025 18:29:12 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Mon, 10 Nov 2025 18:29:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to; s=fm3; t=1762817352; x=1762903752; bh=7Iu/hM9NlwRhNdjLL9LpUQgFbH3lV69r NHp26q1cMTc=; b=gylvvv/5F+HcrKD3JcjKNmhrN0EttQxBvbDc+oN6o5uacubr Yw/M1AJUkU61lXe0dxM9OjUTVIFbZljfknhyiNPGwHpDRgyLfhP8CXOIhfYeOPbp BxZmPfORp1P1/F/Z8KK0t9Tc97HZG4wA3LlZdLviS2zPqvE55ZGqnA1cJsj+sqQ3 HyEU7NlW2v7jzTc4i8jQtTRL3DfdIlsQUiRGeOE7zh1VjR4rYaTb8u3/H9FQS8Vb ebpwi9DegtS9NrLbBaC3MU7y7dJop3t78RCFVOf8zDAAQY7JfOMLICYnJEm0N19E 2uZ+YXY90Drxf4ryHGZ2e5mipkPK2fFMMBnYzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1762817352; x= 1762903752; bh=7Iu/hM9NlwRhNdjLL9LpUQgFbH3lV69rNHp26q1cMTc=; b=Z qCnOIv1XHtNjyMHhQ1Itpl2z8ejAlqJfKfA0kjA/RAQbXob/H9Ndb85c3s6hWEzy L3YzDm2Kk1ZMpH0u2cASe87OnBNgUKYsJ1iHZA5vr8sbExexehLUpld6CaD3qJ1U M0NPGv9yXN7ANwXIe9oHs3swVnhEgL0nsXeM45y4q0eBBg7riR06Y4lccl7rntfv 1P+aADdM0w2IVAWfiQqtfrxd3Uy8r1Yu6PPsXFlZf7XDAIbDk+eJ1Tx/caxEHHcC bxgETpnoEXyK30Fuj7udKj1/7+gXD7Macw5Ut/kxKffy3SWOzTZt6hlS7mOfum5R dkkt7f1OFp894qPw9xPog== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduleelieefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfggtggusehttdertddttd dvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgv rhhnpeeukeejhfeludeitdethfffjeeiuefghedtfeelvefgudeiueevvdeiudejhfdtle enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvohhi ugesfhdqmhdrfhhmpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprh gtphhtthhopehfrhgvvggsshguqdgtuhhrrhgvnhhtsehfrhgvvggsshgurdhorhhgpdhr tghpthhtohepfhhrvggvsghsugdqrghrmhesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Nov 2025 18:29:11 -0500 (EST) Date: Mon, 10 Nov 2025 23:29:10 +0000 From: void To: freebsd-current@freebsd.org Cc: freebsd-arm@freebsd.org Subject: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount Message-ID: Mail-Followup-To: freebsd-current@freebsd.org, freebsd-arm@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; format=flowed Content-Disposition: inline X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.57 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.974]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.155:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:151847, ipnet:103.168.172.0/24, country:AU]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4d55Tp0qSBz42XL Hi, On a newly installed FreeBSD-16.0-CURRENT-arm-armv7-GENERICSD-20251103-088ced14a69b-281661.img unmodified settings 32GB mmcsd. fstab entry for swap is: /dev/label/growfs_swap none swap sw 0 0 swap in top shows: Swap: 1928M Total, 1928M Free # sysctl kern.maxswzone kern.maxswzone: 0 ??? how to fix/should I fix? -- From nobody Mon Nov 10 23:33: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 4d55Zc4qySz63dy4; Mon, 10 Nov 2025 23:33:28 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-a2-smtp.messagingengine.com (fout-a2-smtp.messagingengine.com [103.168.172.145]) (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 4d55Zb1fn3z43qd; Mon, 10 Nov 2025 23:33:27 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=bFyXM6o5; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=Is1AEbFO; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.145 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfout.phl.internal (Postfix) with ESMTP id A02BFEC019D; Mon, 10 Nov 2025 18:33:26 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Mon, 10 Nov 2025 18:33:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1762817606; x=1762904006; bh=Ir0/4tKxuH sHGEyt2I+q88DQxe3GuUwQPSpRIa/UVbU=; b=bFyXM6o5S7uduFlA6wgCrcFh0c MGnuLyKiIwGCMLpKge17qOoMaEFByz+SqJL+HmpO2eGMuYPJqLbEpHSKF0hzdkSc +S3CjHPm7FErGgf1b2qXne1revT0NJcvf2/7VOQMCAIK16prikFtZnDiVuRqamxk Ud6YmMMCtXy4JUxRuR9AEPuIUU0TtDBlrEakpIy6AJ1/r7zoADrJ9bHfKdEOrkM2 WpwK0g1E1JWea5JdXSU3KRRZAl10CmohjIUgUuGzhkgIEmAdQ/xQcVg9U+L4cGKf nTFkp5SW7j7IbL0mIozL7xlrCwcXXCZ2BjEq8gqhhcsIOMVHCU5Xxww/zU6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1762817606; x=1762904006; bh=Ir0/4tKxuHsHGEyt2I+q88DQxe3GuUwQPSp RIa/UVbU=; b=Is1AEbFOyb+1WVBozX4hUGQ2/oj8d+2AuSn+Ls7EZyWfHal4hIb iSb2lep0Yx51aCnPe6Pw9ill/DvXR1uN1PLKMxqctxuYgCPqs2srbLfPMuimSi+q CTmd3e/VFyI+vyXTjA9wm2/MXSql8f4BmuZHYhc6XIYX3XBVtjRGnfYl5txK8nKS v90I3bfKJ6ek0inNvOOGFQvh1Rslaw7ZAWwg1TYZxxwUrkByOt0fLPmlkovIeHyg zR25NnBkArH2ume4UZ3gmMmnGn49ezyezFPKo4YEjBBeg1pqzarmE8khep89Y7z9 8ESbTgyMSB00Hlnxoq0AfVCp07OHo6ksr+w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduleelieegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddtheehgf eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpd hrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrghdp rhgtphhtthhopehfrhgvvggsshguqdgrrhhmsehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Nov 2025 18:33:25 -0500 (EST) Date: Mon, 10 Nov 2025 23:33:24 +0000 From: void To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount Message-ID: Mail-Followup-To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.57 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.975]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.145:from]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4d55Zb1fn3z43qd On Mon, Nov 10, 2025 at 11:29:10PM +0000, void wrote: >Hi, > >On a newly installed >FreeBSD-16.0-CURRENT-arm-armv7-GENERICSD-20251103-088ced14a69b-281661.img > >unmodified settings 32GB mmcsd. > >fstab entry for swap is: > >/dev/label/growfs_swap none swap sw 0 0 > >swap in top shows: > >Swap: 1928M Total, 1928M Free > ># sysctl kern.maxswzone >kern.maxswzone: 0 > >??? > >how to fix/should I fix? Sorry in case it's not obvious, the error is in the subject line: "kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount (493248 pages)." -- From nobody Tue Nov 11 00:27:05 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 4d56mm4kHPz63jjh for ; Tue, 11 Nov 2025 00:27:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 4d56mm24ndz3Dqk for ; Tue, 11 Nov 2025 00:27:20 +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=1762820837; bh=TF/KDLdMTw79WFGkVfMfeSpYrvO8MDuDadZpwTdev6M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mYfvvzh4wiWKjEHyPoaoQY6pL910o86O7n0w97CSWuLOO0z2pV3MkpXWbLF5D9AfYiAKca0QCQBoxl9xMdV3bts1wEx9cqJMSAWJQrGLdrfH2skGTJhMQmc4oa36Oj50cXSXgG7DFxQEEMV0KfTvj7reiqHumU9VG84tAge7rIk7hX9memESStYhzOApILltRMFEzADQoUT2U/RDYurSzsSzGrVkvY9dwGtM9HVlM2kJEgccVvkWVAnhiPDvpk/Yy597xmebwhciQoYVcGKrRzHfjq6yQB1sfdzvEM8mk4bsMJ4YjVy6OIbkgMfV2HEU9UewU6isRsJ5MEN6hwyZaw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762820837; bh=AGM/KwB6TZ41s0IOs1KdPMbPgevKdUQXMQOZ1Ihz4y7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uMu2tsN5hEsqbt/dT0A9hnucCajQMUuGwLAihYEroE9b30aN8F8+HBBbwnv7nKn2y/6xj0pIqGtIQ9jJ13vGVK1sctGZkdA/j7OA40x2hDgusoGMupiI7camrHtd1M+IE1CsocQTRxKTSmqLr7P5tHsrMj7+5VoY/O0mWFXyDhR7Oe69Rsel5R8WB2OuM42qD5uhnriNzJmr84yJMfe0RONPzcZQu9zm821NXGnFc3uNWBAYf8sbQ3aDyPl2O2J/20157JZ1bLXCZ3mScx5R2VLVZHXf+81tzbKNkC9lo/IWJwAUdGFBTYz6Um2664kpMdbn7dqfF43m0gl7epWugQ== X-YMail-OSG: 7BvGjZQVM1nnSTO5lQOPP7gDSovOzDbQkPfRMTE0bLtCJyi4kzWsPSeucUcPfYc 9PqM_LnvWTdTRZpjDh_T78jIL_ly7rNCSl7JoBDpig7TpVY0SasuStKDfDLNnTwg.lyGOJxKHH3A hiqc5IIJWuOfW6F6vrot3K79DKcLhBamhW4M8AbFVCXognreKdkfpM_wsDfsyp7yVl5FhXsVDKP3 FzgW8bg0TlZDaXh0YgECQIwnEiLP5xj9Zd1EQhPdpCebHcrzAy_1qJMDWUp7syTzsV_5G.gVxZZE jNTyh.rDXtsm8FbNaXD8PQpduYc0QWf8qbaM2o54wVaIzl4u2aRG0DKZQDcUKAsmb8UkER.WcWE2 n0aFaiUHZQ9dm6REC.RxU0_Kpups2jA2fjMtwALPhDmSwh1dOk09eKiYG2PzlI6FdbJwFoh1shwk 6gbSm_Hvqk75M2bsrqI07p3dxIEN7R3oY8DE5P9PDhSYqB5hb4LWWWGMQn.BZFuRsUI2b9_IL2o3 rTIGSH4WrFqfQsmkYrYnADmpkCiLbqBJXdDhPtK59xTqIJXROf313njeo4zlfFUf3fdp0GGy3DEP cYdnLcSCGZq40RgGFSEjeKm8cQKfFcUzJ19juD1QKjxZehEI0nHeowDoU9JwLgqc9YlajRNnIabp SFkXBw0qaAO9terPTYTzhnzLPwdtI.Vrb6Tu.5apsNTPXEywrz_kz5Bm4C4lj7vJ_oepC25ctBy3 Is8l7B0x4.5INNJ7V7v6PjAOr4_KVt1J8m8TdYgQFDlNGNTHDbsHgkrN5kwVslLROmU0UNVaTb0f MfVxOLxQcVqY4KAkTxS2pPhIXbsa0_za81eneyJ14OVyCDfHVFNRqaQpEZYI3DV.mttp._RyWx5Y BNtP27kpL.uYY1u7_x1u0H4IVxpPRbIWh5NXkeYbbMoXdC8Y1sixg2NB2OGFRNdozBMwwbBql70l nFOBGLJCVHg0K8VwRR.n1WtPdr5uXSxBc4C83QoaP2lzx7AAmmqz5wmr08..ohdDpnL8u6W1Dwfl QWdabu_jmqSzjRbCntX_2FsOydMYVjDCYo6Zf46_puhADbtSqRBzkXQ_VvgqZ9FOiiedHK9.2lvX KZdXq7ArGz04kyVnf_8xCDsDcChBAbERdp_Fhydv6xcsuLZyXCV2uX_n7eNjMZdMMIYQIs1EpAjt Zx1XaSTMY1NBqJYQA4K3Nx3H84A7uIGCt5YRDupD9iG0FhFQ0_rwjSdOLhu.lKe1AjTxG3bCAecV d.DS5pF9MH_f3chnMDn0wbYoqk86IJkXBGCslXjAmt60rgFSr7dLDU79Cw_m28tLDtglwkZ7Dqok _zrCwyMj_ERGkKHxeMUkwW7f.Bn_Qa.qWIySEFP4iuh55uJV1cnKej_rZ1LKpwBter6NWYufBMAa qjXhHHCrT.ltYB5Y93qlTacHduQ45K9AqqUkBS_YjuLOzg33Aa6ryjV5vm29yGZnK43kcuGH2oCz 1Wr4E1uBWlr4F0fVxMyz7EMEhUZ3H_kGXBA5qKSvWcuQpUIhwBafhgTo5M1VgpusgGeeg5NKSo4q YolvEuRO64r7mPXlaOERGk.fOKHHdJJIalijTcZtsdh7zTCbHgzEzHAENcAGVS16vhipAImpRs3w ukCEPhmQJJ.roeGqZFckFXO4QBPrMBdHP58UjBRw927xUX5.ysa2VJFFmxwwHPOYA6L3uUIyHRYS QSTlhFllkkptZqpqWymAWw6ameG5rC33AYS5ztYAoy326Goy8Wk3t7wS2G7Ihuw4Dwv7fc1299H1 444S8ZliKflWGYUQFlAd.3Z_QhFP_2CgdyNUB4WQi8DQCjGLGc7fbvBDQhSd2GwqNZWvWAOPwAwu cMWgmc9pSTJZXeFH8bkv2.D1TsVFv2RPNklScsrsnH8O4r9ikUGtUMvTUM1jUBVKEO1SahPj0gdp EyjHsdqCe3E84Ea_NObFCbEHEjQ7L.6RWfoOVYf.bAgif0xyHMBY4YGb_3q.On9pCsyMm3eIO67o CPK3CYfZ.dAJ3QoxwUlpZU0W7E.VSCo_hsZS4mePhhbZfvLFkCdeONecZpiF9cKFzEKwSqbUdEVp vUU8ld0UqP5XjKkJX62bxgyqGOIqau6UopykX23D0uGOhSJjM9bPHd2ylm2.m2NGWT7UjoD6Q8Us kneNkZDju.eBCgq23HahkxwLlnddPiXLOf6TfWsHAF2jgY7CqHCQHyN_GzUYy1Eg_LTzthtyK5kS E8szJFfx85RHVo1TExIVwrSdjETJjh1hwVWEftCW61StbgblSCGyThslM9OCfMHFQKU8VGRtSVAo gQj8- X-Sonic-MF: X-Sonic-ID: 0847e7b0-589e-44d1-abf2-d59ecf0b496e Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Nov 2025 00:27:17 +0000 Received: by hermes--production-gq1-86c5846576-stdgl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5d34bec0cb450226a2a199954a5a935a; Tue, 11 Nov 2025 00:27:15 +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.700.81\)) Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount From: Mark Millard In-Reply-To: Date: Mon, 10 Nov 2025 16:27:05 -0800 Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <64F173A2-FCA4-4E94-9E21-B2B0744E6092@yahoo.com> References: To: void X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d56mm24ndz3Dqk On Nov 10, 2025, at 15:33, void wrote: > On Mon, Nov 10, 2025 at 11:29:10PM +0000, void wrote: >> Hi, >>=20 >> On a newly installed >> = FreeBSD-16.0-CURRENT-arm-armv7-GENERICSD-20251103-088ced14a69b-281661.img >>=20 >> unmodified settings 32GB mmcsd. >>=20 >> fstab entry for swap is: >>=20 >> /dev/label/growfs_swap none swap sw 0 = 0 >>=20 >> swap in top shows: >>=20 >> Swap: 1928M Total, 1928M Free >>=20 >> # sysctl kern.maxswzone >> kern.maxswzone: 0 >>=20 >> ??? >>=20 >> how to fix/should I fix? >=20 > Sorry in case it's not obvious, the error is in the subject line: > "kernel: warning: total configured swap (493567 pages) exceeds maximum = recommended amount (493248 pages)." It is not so much an error message as a waring that the system might be mistuned, in this case by a small fraction of the maximum recommend amount: (493567-493248)/493248 approx.=3D 0.00064673 Normally the line that you report also has an associated line that, to me, reads as easily misleading in part: warning: increase kern.maxswzone or reduce amount of swap. The warning is not explicit about any tradeoffs involved for increasing kern.maxswzone . (Personally, I avoid using combinations that produce the warnings, since I do not have an understanding of any detailed tradeoffs, including for leaving things as the messages report. I have been told in the past that the warning is associated with an increased risk of deadlock/livelock. That need not mean that the risk is zero at the maximum recommended. Also, I've no know way to determine when such a status is actually contributing to a problem.) For 64-bit systems, having SWAP=3D3.6*RAM normally does not complain. SWAP=3D4*RAM complains. =46rom build to build the point for getting warnings moves some in that range. (This is based on experience, not calculations from what the kernel code does.) 3.6 was picked to have some margin. For 32-bit systems, the factor is notably smaller. If I remember right SWAP=3D1.7*RAM has some margin and SWAP=3D2*RAM always produces the warnings. More detailed information based on the man page content that is related follows. It is from an old Email that I'd sent out to the lists. START OLD EMAIL I'll be more explicit relative to this for how I've taken that text historically. QUOTE kern.maxswzone Limits the amount of KVM to be used to hold swap meta- data, which directly governs the maximum amount of swap the system can support, at the rate of approximately 200 MB of swap space per 1 MB of metadata. This value is specified in bytes of KVA space. If no value is pro- vided, the system allocates enough memory to handle an amount of swap that corresponds to eight times the amount of physical memory present in the system. END QUOTE The TheoreticalMaxSWAP=3D8*PHYSMEM figure is specific to 64-bit contexts, if I understand right. It is smaller for 32-bit contexts as far as I can tell. Certainly the warnings for 32-bit suggest so. QUOTE Note that swap metadata can be fragmented, which means that the system can run out of space before it reaches the theoretical limit. Therefore, care should be taken to not configure more swap than approximately half of the theoretical maximum. END QUOTE So, for 64-bit systems, closer to MaxSWAP=3D4*PHYSMEM. The warning show up at somewhat less than that. I'd guess that the kernel's calculations are the more accurate vs. the above wording. QUOTE Running out of space for swap metadata can leave the sys- tem in an unrecoverable state. Therefore, you should only change this parameter if you need to greatly extend the KVM reservation for other resources such as the buffer cache or kern.ipc.nmbclusters. Modifies kernel option VM_SWZONE_SIZE_MAX. END QUOTE I wonder if "only change the" should be "only increase the", as only that direction would seem to limit the space for buffer cache or kern.ipc.nmbclusters or other such. Either way, I'd take that wording as contradicting the: "increase kern.maxswzone" part of: "warning: increase kern.maxswzone or reduce amount of swap." wording unless one knows that the buffer cache and kern.ipc.nmbclusters and such tradeoffs would be reasonable for the context. I do not have that kind of knowledge about the tradeoffs. Someone once told me that the tradeoff was probability of the kernel deadlocking when trying to manage the resources. I assume that is accurate but do not know it for sure. So, historically I've taken the warning seriously but always via the "reduce amount of swap" part of it. END OLD EMAIL =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Nov 11 01:40:49 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 4d58NP258zz64L8s; Tue, 11 Nov 2025 01:39:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d58NL54Zvz3Pmx; Tue, 11 Nov 2025 01:39:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AB1eni6021673 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 10 Nov 2025 17:40:50 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AB1enmj021672; Mon, 10 Nov 2025 17:40:49 -0800 (PST) (envelope-from fbsd) Date: Mon, 10 Nov 2025 17:40:49 -0800 From: bob prohaska To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount 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-Spamd-Bar: - X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[zefox.net]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4d58NL54Zvz3Pmx On Mon, Nov 10, 2025 at 11:29:10PM +0000, void wrote: > Hi, > > On a newly installed > FreeBSD-16.0-CURRENT-arm-armv7-GENERICSD-20251103-088ced14a69b-281661.img > > unmodified settings 32GB mmcsd. > > fstab entry for swap is: > > /dev/label/growfs_swap none swap sw 0 0 > > swap in top shows: > > Swap: 1928M Total, 1928M Free > > # sysctl kern.maxswzone > kern.maxswzone: 0 > > ??? > > how to fix/should I fix? I've not seen any recognizable benefit in heeding that warning, but YMMV I've two Pi2's with 3.6G of swap and one with 1.7G of swap. All misbehave in the same way. If using USB you could try something like (as root) swapoff /dev/da0s2 gpart resize -i 2 -s 1700M /dev/da0s2 swapon /dev/da0s2 If using microSD I'd be wary of swap; some very mysterious file corruption emerged on a Pi3 which had swap on the microSD. Not your situation, of course, just a cautionary tale. FWIW there is a random collection of "notes to self" at http://www.zefox.net/~fbsd/ It's poorly organized, out of date and at least partly wrong. HTH, bob prohaska > From nobody Tue Nov 11 12:45: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 4d5R8h04Prz6GPDJ; Tue, 11 Nov 2025 12:45:40 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-b1-smtp.messagingengine.com (fout-b1-smtp.messagingengine.com [202.12.124.144]) (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 4d5R8f70DNz3vlb; Tue, 11 Nov 2025 12:45:38 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=GHC4YVuJ; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="Kp/KqfKw"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.144 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id 52BA01D0014D; Tue, 11 Nov 2025 07:45:38 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Tue, 11 Nov 2025 07:45:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1762865138; x=1762951538; bh=ln6IbBGF7x QHbZw8T2yPcLRb7XDjXMJB65t4e7fGmGc=; b=GHC4YVuJByZyxeg1AKdxQ1/Asb KPlX5zVzep9cyHn26pMbg6ktxjnEOj9/DTC0JjyRAEcx/wrTeWdkbBsY1V4Pb0vV bom3GliU7pTaizPsM5H1PZ+jwGChru5VwpkgcPDoFUQtmyaT82mI3xT4xkhJyM3s aRviMEZ0TkjYrUuwDTb5WSFO1bPQK+Ki3WcJsBwWppnq7usmZPp+6YZlo62iLTzV 7Vst0beTdCpwJGpvsvQdQnXKosN+Ykoex1TqciPC0cO2JNFzfSPclKqGDxmf8TyL ZMInf4OD0ESN0Xy1bggfuzhYrnOZTruSd8rvDk+w6koTsrHMoqCvrG3WQGkw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1762865138; x=1762951538; bh=ln6IbBGF7xQHbZw8T2yPcLRb7XDjXMJB65t 4e7fGmGc=; b=Kp/KqfKwXsmaKOj6D1wYoc0nvmeF21496PhzLSyhFBLE1FNuM7r GH/C9Tw1rdugl32v3AS+LL7x5GGA9WPzUq8bV6OXoxznmhnUbDHLpnwPcVYhCDhQ gdMHsOQIOzvrwBnN5MjL2e6KeNP+CZgbB2gf9UfL+NqlijQWuQXopGL1MfW9BXbS qk/oD7N0CaSvNwmloKZgIA+EWm0069h/lMe3ytUBorGclvmMAv+DA0PaBVF31bcn tLlDT+wcCZnCslNdJkVEqVo2Ui/FPBEg7lwBaFP1qNHrpa2h39qIKuATK5gdT/fd OzCLJxQc0o/orWzzecjmYFToMgaFobZc4Gg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvtdduvdefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepgeeuudfffefhgfejtefgjeevveekgefhfedvieetfedttdekgffgudevgffgvd fgnecuffhomhgrihhnpeiivghfohigrdhnvghtnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtghpth htohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghu rhhrvghnthesfhhrvggvsghsugdrohhrghdprhgtphhtthhopehfrhgvvggsshguqdgrrh hmsehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Nov 2025 07:45:37 -0500 (EST) Date: Tue, 11 Nov 2025 12:45:35 +0000 From: void To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount Message-ID: Mail-Followup-To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Bar: / X-Spamd-Result: default: False [0.40 / 15.00]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; MID_RHS_NOT_FQDN(0.50)[]; URIBL_RED(0.50)[zefox.net:url]; NEURAL_SPAM_SHORT(0.39)[0.392]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.144:from]; HAS_ANON_DOMAIN(0.10)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; R_DKIM_ALLOW(0.00)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DMARC_POLICY_ALLOW(0.00)[f-m.fm,none]; R_SPF_ALLOW(0.00)[+ip4:202.12.124.128/27]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4d5R8f70DNz3vlb On Mon, Nov 10, 2025 at 05:40:49PM -0800, bob prohaska wrote: >On Mon, Nov 10, 2025 at 11:29:10PM +0000, void wrote: >> fstab entry for swap is: >> /dev/label/growfs_swap none swap sw 0 0 >I've not seen any recognizable benefit in heeding that warning, but YMMV >I've two Pi2's with 3.6G of swap and one with 1.7G of swap. All misbehave >in the same way. > >If using USB you could try something like (as root) >swapoff /dev/da0s2 >gpart resize -i 2 -s 1700M /dev/da0s2 >swapon /dev/da0s2 I'm thinking maybe raising this as a PR because that swap thing - it came as-is, pre-installed. I downloaded the Nov 3rd armv7 snapshot, wrote it to mmcsd and it was there. I have no idea how to resize or otherwise modify /dev/label/growfs_swap or if it's a device or a file. Raising it as a PR because if incorrectly sized by default then that's a fault. I had planned to remove the above swap entry anyway and instead have swap nfs-mounted. it'd be faster than anything local on the rpi2b. >If using microSD I'd be wary of swap; some very mysterious file corruption >emerged on a Pi3 which had swap on the microSD. Not your situation, of course, >just a cautionary tale. It's on the microsd by default for 16:main for armv7 too as per above >FWIW there is a random collection of "notes to self" at >http://www.zefox.net/~fbsd/ >It's poorly organized, out of date and at least partly wrong. Thanks, I'll have a read. -- From nobody Tue Nov 11 12:55: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 4d5RMw2x0Pz6GPd0; Tue, 11 Nov 2025 12:55:24 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4d5RMw0lggz3yf6; Tue, 11 Nov 2025 12:55:23 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmlive5.colo2.realworks.nl [10.2.52.25]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4d5RMs3zrfz1Z1; Tue, 11 Nov 2025 13:55:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1762865721; 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=h3nQAqbJCg7IFU3Z6S1FQTvEGZJp9Yx8JbKDqt/6jcc=; b=LJg1LX2UQWkwq11Kdb7QI3P3zOXtN63i8TxITZtdCNvsZzebAdkOS9AxqOI0v8lOLtYkPp UW/Ewtu/Zh2mOkFJsCci/EcGDYCT5Zu8H7Hf+dSp7tQFozbZtv5b8LBW0hlycm8Srfqzxk uYiWwMpnqYzw0zrpY47BSLvxyKhWEh8Kz2twBngW/8M8DFWxzZEs5+agG/s1P1T7t4Bb5N cg11Y+BAHu+UiPgReyUrq2zm8A1QzDo8jkkXwZW9utz9wML/F+WWz8pEoxATPklLqSGKNv X2I/veN7G9TwRzdOVkBvtXMEIfqYpiiC+F5/eUsSaC1dTs6IF5ULj1lWIeTI5Q== Received: from crmlive5.colo2.realworks.nl (localhost [127.0.0.1]) by crmlive5.colo2.realworks.nl (Postfix) with ESMTP id 66CE912386E; Tue, 11 Nov 2025 13:55:20 +0100 (CET) Date: Tue, 11 Nov 2025 13:55:20 +0100 (CET) From: Ronald Klop To: void Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Message-ID: <1155875772.165920.1762865720265@localhost> In-Reply-To: References: Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount 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/alternative; boundary="----=_Part_165919_1106108671.1762865720258" X-Mailer: Realworks (771.77) X-Originating-Host: from (83-81-212-149.cable.dynamic.v4.ziggo.nl [83.81.212.149]) by crmlive5 [10.2.52.25] with HTTP; Tue, 11 Nov 2025 13:55:20 +0100 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:144.0) Gecko/20100101 Firefox/144.0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d5RMw0lggz3yf6 ------=_Part_165919_1106108671.1762865720258 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, You can take a look at the script /etc/rc.d/growfs . It runs on firstboot. The script contains a comment explaining what it does. Regards, Ronald. Van: void Datum: dinsdag, 11 november 2025 13:45 Aan: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Onderwerp: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount > > On Mon, Nov 10, 2025 at 05:40:49PM -0800, bob prohaska wrote: > >On Mon, Nov 10, 2025 at 11:29:10PM +0000, void wrote: > > >> fstab entry for swap is: > >> /dev/label/growfs_swap none swap sw 0 0 > > >I've not seen any recognizable benefit in heeding that warning, but YMMV > >I've two Pi2's with 3.6G of swap and one with 1.7G of swap. All misbehave > >in the same way. > > > >If using USB you could try something like (as root) > >swapoff /dev/da0s2 > >gpart resize -i 2 -s 1700M /dev/da0s2 > >swapon /dev/da0s2 > > I'm thinking maybe raising this as a PR because that swap thing - it came > as-is, pre-installed. I downloaded the Nov 3rd armv7 snapshot, > wrote it to mmcsd and it was there. I have no idea how to resize or otherwise > modify /dev/label/growfs_swap or if it's a device or a file. > Raising it as a PR because if incorrectly sized by default then that's > a fault. > > I had planned to remove the above swap entry anyway and instead have > swap nfs-mounted. it'd be faster than anything local on the rpi2b. > > >If using microSD I'd be wary of swap; some very mysterious file corruption > >emerged on a Pi3 which had swap on the microSD. Not your situation, of course, > >just a cautionary tale. > > It's on the microsd by default for 16:main for armv7 too as per above > > >FWIW there is a random collection of "notes to self" at > >http://www.zefox.net/~fbsd/ > >It's poorly organized, out of date and at least partly wrong. > > Thanks, I'll have a read. > > -- > > > > ------=_Part_165919_1106108671.1762865720258 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

You can take a look at the script /etc/rc.d/growfs .
It runs on firstboot. The script contains a comment explaining what it does.

Regards,
Ronald.

 

Van: void <void@f-m.fm>
Datum: dinsdag, 11 november 2025 13:45
Aan: freebsd-current@freebsd.org, freebsd-arm@freebsd.org
Onderwerp: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount

On Mon, Nov 10, 2025 at 05:40:49PM -0800, bob prohaska wrote:
>On Mon, Nov 10, 2025 at 11:29:10PM +0000, void wrote:

>> fstab entry for swap is:
>> /dev/label/growfs_swap  none            swap    sw              0       0

>I've not seen any recognizable benefit in heeding  that warning, but YMMV
>I've two Pi2's with 3.6G of swap and one with 1.7G of swap. All misbehave
>in the same way.
>
>If using USB you could try something like (as root)
>swapoff /dev/da0s2
>gpart resize -i 2 -s 1700M /dev/da0s2
>swapon /dev/da0s2

I'm thinking maybe raising this as a PR because that swap thing - it came
as-is, pre-installed. I downloaded the Nov 3rd armv7 snapshot,
wrote it to mmcsd and it was there. I have no idea how to resize or otherwise
modify /dev/label/growfs_swap or if it's a device or a file.
Raising it as a PR because if incorrectly sized by default then that's
a fault.

I had planned to remove the above swap entry anyway and instead have
swap nfs-mounted. it'd be faster than anything local on the rpi2b.

>If using microSD I'd be wary of swap; some very mysterious file corruption
>emerged on a Pi3 which had swap on the microSD. Not your situation, of course,
>just a cautionary tale.

It's on the microsd by default for 16:main for armv7 too as per above

>FWIW there is a random collection of "notes to self" at
>http://www.zefox.net/~fbsd/
>It's poorly organized, out of date and at least partly wrong.

Thanks, I'll have a read.

-- 
 

  ------=_Part_165919_1106108671.1762865720258-- From nobody Tue Nov 11 13:50: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 4d5Sbp40WZz6GSqj for ; Tue, 11 Nov 2025 13:50:46 +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 4d5Sbn42yWz47FH; Tue, 11 Nov 2025 13:50:45 +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 5ABDoFRC018013; Tue, 11 Nov 2025 15:50:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5ABDoFRC018013 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5ABDoFwx018012; Tue, 11 Nov 2025 15:50:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Nov 2025 15:50:15 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Don Lewis , Ronald Klop , "Peter 'PMc' Much" , FreeBSD CURRENT Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? Message-ID: References: <2100145914.14642.1762672441817@localhost> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: / X-Spamd-Result: default: False [-0.49 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_XAW(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4d5Sbn42yWz47FH On Mon, Nov 10, 2025 at 01:02:54AM -0800, Rick Macklem wrote: > On Mon, Nov 10, 2025 at 12:15 AM Don Lewis wrote: > > > > On 9 Nov, Rick Macklem wrote: > > > On Sat, Nov 8, 2025 at 11:14 PM Ronald Klop wrote: > > >> > > >> > > >> Van: Rick Macklem > > >> Datum: 9 november 2025 00:23 > > >> Aan: FreeBSD CURRENT > > >> CC: Peter 'PMc' Much > > >> Onderwerp: RFC: Should copy_file_range(2) return after a few seconds? > > >> > > >> Hi, > > >> > > >> Peter Much reported a problem on the freebsd-fs@ mailing > > >> list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > > >> hang for hours?". > > >> > > >> The problem was that he had a copy_file_range(2) copying > > >> between a large NFS file and a local file that was taking 2hrs. > > >> While this copy_file_range(2) was in progress, it was holding > > >> a rangelock for the entire output file, causing another process > > >> trying to read the output file to hang, waiting for the rangelock. > > >> > > >> Since copy_file_range(2) is not any standard (just trying to > > >> emulate the Linux one), there is no definitive answer w.r.t. > > >> should it hold rangelocks. However, that is how it is currently > > >> coded and I, personally, think it is appropriate to do so. > > >> > > >> Having a copy_file_range(2) syscall take two hours is > > >> definitely an unusual case, but it does seem that it is > > >> excessive? > > >> > > >> Peter tried a quick patch I gave him that limited the > > >> copy_file_range(2) to 1sec and it fixed the problem > > >> he was observing. > > >> > > >> Which brings me to the question... > > >> Should copy_file_range(2) be time limited? > > >> And, if the answer to this is "yes", how long do > > >> you think the time limit should be? > > >> (1sec, 2-5sec or ??) > > >> > > >> Note that the longer you allow copy_file_range(2) > > >> to continue, the more efficient it will be. > > >> > > >> Thanks in advance for any comments, rick > > >> > > >> ________________________________ > > >> > > >> > > >> > > >> Why is this locking needed? > > >> AFAIK Unix has advisory locking, so if you read a file somebody else is writing the result is your own problem. It is up to the applications to adhere to the locking. > > >> Is this a lock different than file locking from user space? > > > Yes. A rangelock is used for a byte range during a read(2) or > > > write(2) to ensure that they are serialized. This is a POSIX > > > requirement. (See this post by kib@ in the original email > > > discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-October/004704.html) > > > > > > Since there is no POSIX standard for copy_file_range(), it could > > > be argued that range locking isn't required for copy_file_range(), > > > but that makes it inconsistent with read(2)/write(2) behaviour. > > > (I, personally, am more comfortable with a return after N sec > > > than removing the range locking, but that's just my opinion.) > > > > > > rick > > > > > >> Why can’t this tail a file that is being written by copy_file_range if none of the applications request a lock? > > > > Since writes don't go backwards, it would seem to make sense to advance > > the start of the range lock as the copy proceeds. > The current code does the rangelock above the VOP layer and, > for ZFS, if block cloning is enabled, the entire copy happens > all at once and fairly quickly (it's copy on write as I understand it). > > I can't recall for certain, but I think the rangelock must be acquired > before the vnode lock(s), so I don't think moving it to below the > VOP layer is practical? Yes, rangelocks were introduced because it become required to be able to drop and reaquire the vnode lock during VOP_READ() and VOP_WRITE(). Then vnode locks do not protect the file content anymore. Due to this re-locking, rangelocks have to be before the vnode locks. To support the proposed downgrading of the written range we would need somewhat non-trivial operation on rangelocks. Basically, the owner of the write lock needs to atomically delegate part of its range to the new read lock. And rangelock unlock must clear all of them. It might be possible, but sounds quite complicated. > > rick > > > As long as the read > > position + length is before the write position, there is no reason to > > block the read. Running "cat outfile" would look a lot like tail -f > > because cat would only see the new data because it would temporarily > > block if it ever caught up with the copy. > > > > tail is a bit funky, though. If the size of the destination file is > > updated periodically during the copy, tail could return early with an > > earlier part of the file. If the size is updated immediately to the > > final size, then tail will wait for the copy to complete, but will > > output the true end of the file. > > > > What about backups? > From nobody Tue Nov 11 14:33: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 4d5TYg2Q3rz6GWpX for ; Tue, 11 Nov 2025 14:33:59 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 4d5TYf542Bz3DTr for ; Tue, 11 Nov 2025 14:33:58 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=MC25O5Wh; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::733 as permitted sender) smtp.mailfrom=markjdb@gmail.com Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-8b1e54aefc5so380687785a.1 for ; Tue, 11 Nov 2025 06:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762871636; x=1763476436; darn=freebsd.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=QaCy7HaeMw1N+tXYBxjxOMX1xCMpas15gI9fTUQm9uM=; b=MC25O5WhjdGQLPAJV6/p9voimd1fKGj0fp9hHWylwuoWSFlPWc/mUk+uE0TUAfomLP sugddnDQUT+3PO7oYhci0oZeLnbt5UWitl9VpHGMKHhiS6ZmFkLh4qNk8h8b2J85YWWv viX/yCCyQrZ9o5bOVSCvhrFNSetlYw1GpH74bXxIGAQY/qNTn6PL+a6N2U1NIsnZb9Hc On+XOjRm1a/r1uUnLOHa93/bHcfBMbGe0rBJrZ3TxC5u/98vpK6Q4sV/xKPIWlQ+G6BU bB0cDgu8k4XT4PNK9frJI5YvcYgptchnfqbe0eE9aGjHZC7j6m+17kwfSEVyg83dfrFg 8pMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762871636; x=1763476436; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QaCy7HaeMw1N+tXYBxjxOMX1xCMpas15gI9fTUQm9uM=; b=GIHYctUd0QfKcmPOE2Vpuf+F1lsmjwLluGdgXDwKxExNQgoJcTl01707ISG877c4Ei HyCIG+rkBBYx14K0QsvjdqHNIAeuBxSO1ZKLNTiNaOjFYREODhTs+Op64zC3IRylmRev Ms3JyjEaUxjkA168pUnN5dAGd65RplTipDS5vf2GrDi2AsWuDoGjXWzFEJ4BSv6Raj5j RorvBiaUP9WyDPqtM8aPCrSKW2858wUZWdHbUknmKZTHSAdZO9jE3WL3oruId/g27PXf 85sJhrNyQf0UDKnE1fsupgfM2jJv5cmdrcB0zheRKjTHYOIVQRU16kH0BxSe4odi676F kYgQ== X-Forwarded-Encrypted: i=1; AJvYcCV88BTsNlZlJxZ8ejldfkgl27QQ/lMAcr14z2aZhe7XSLiBtC+EbwyQRJTUqw0tO2dprHCoE9aFvXGmz4tGQFo=@freebsd.org X-Gm-Message-State: AOJu0YzyE1rslG2tU+ZFTbZ6P8kO+x5npaLE/b6QpB2uZfRvc/kiwCMc BT6YspcztSOF1A06F1Y/4qzvi8ide5CTd60kGPVLSDlCVArkSeQIX+5V X-Gm-Gg: ASbGncsn8jQfyZu5+TnKbmOgfLs3xojiqNSrThl+AbHQpiegxzzb+l8sbrdnGcCri5n 2Z8BIyrqXGFuyBGMCOOLRLPJooMzEiiiBo5qvZF1A9Tm9jwc/z0DFA0yULwvbfR+sg+ftJzw+l8 ou5TtrQV/ZUgeFUfw0ylx/XeYyqQ09QJZI5Id8PNv6KxwxftQvYV53YmeqNF4I69iGAhj5w9lQ/ dACuCWDlYA9daLfR8+viimBOyAxIE856+ne6Jgl9KINuWIjB685YPF9zqWVIx48Dz+PGSFh1NIc SL08MTMUVQejz7SOD/6Ac2ovyNYhfD8AgfbQiHE5g8I6iLJlMExVuMTs08JAuCyCJqJtrSVkHXu 7foep5PnMWdWlreE5Yhpdyj3BmZX9O32IKVElOmv3K0RtaNR4s9A33idKoPoC+YDrYk9Ujow2xQ dUQNpWhkM= X-Google-Smtp-Source: AGHT+IFCltpNM28KtqKqb9b22VHCv+bouZUAsjn5GBD0SHaBcMDSGadynbamm/fWu73cfBFrwLYIuw== X-Received: by 2002:a05:620a:4891:b0:8a1:21a6:e04f with SMTP id af79cd13be357-8b257f0b56bmr1598902185a.28.1762871636062; Tue, 11 Nov 2025 06:33:56 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8b25e8b409csm704908085a.22.2025.11.11.06.33.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Nov 2025 06:33:55 -0800 (PST) Date: Tue, 11 Nov 2025 09:33:52 -0500 From: Mark Johnston To: Rick Macklem Cc: Don Lewis , Ronald Klop , Peter 'PMc' Much , FreeBSD CURRENT Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? Message-ID: References: <2100145914.14642.1762672441817@localhost> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: / X-Spamd-Result: default: False [-0.10 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::733:from]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4d5TYf542Bz3DTr On Mon, Nov 10, 2025 at 01:02:54AM -0800, Rick Macklem wrote: > On Mon, Nov 10, 2025 at 12:15 AM Don Lewis wrote: > > > > On 9 Nov, Rick Macklem wrote: > > > On Sat, Nov 8, 2025 at 11:14 PM Ronald Klop wrote: > > >> > > >> > > >> Van: Rick Macklem > > >> Datum: 9 november 2025 00:23 > > >> Aan: FreeBSD CURRENT > > >> CC: Peter 'PMc' Much > > >> Onderwerp: RFC: Should copy_file_range(2) return after a few seconds? > > >> > > >> Hi, > > >> > > >> Peter Much reported a problem on the freebsd-fs@ mailing > > >> list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > > >> hang for hours?". > > >> > > >> The problem was that he had a copy_file_range(2) copying > > >> between a large NFS file and a local file that was taking 2hrs. > > >> While this copy_file_range(2) was in progress, it was holding > > >> a rangelock for the entire output file, causing another process > > >> trying to read the output file to hang, waiting for the rangelock. > > >> > > >> Since copy_file_range(2) is not any standard (just trying to > > >> emulate the Linux one), there is no definitive answer w.r.t. > > >> should it hold rangelocks. However, that is how it is currently > > >> coded and I, personally, think it is appropriate to do so. > > >> > > >> Having a copy_file_range(2) syscall take two hours is > > >> definitely an unusual case, but it does seem that it is > > >> excessive? > > >> > > >> Peter tried a quick patch I gave him that limited the > > >> copy_file_range(2) to 1sec and it fixed the problem > > >> he was observing. > > >> > > >> Which brings me to the question... > > >> Should copy_file_range(2) be time limited? > > >> And, if the answer to this is "yes", how long do > > >> you think the time limit should be? > > >> (1sec, 2-5sec or ??) > > >> > > >> Note that the longer you allow copy_file_range(2) > > >> to continue, the more efficient it will be. > > >> > > >> Thanks in advance for any comments, rick > > >> > > >> ________________________________ > > >> > > >> > > >> > > >> Why is this locking needed? > > >> AFAIK Unix has advisory locking, so if you read a file somebody else is writing the result is your own problem. It is up to the applications to adhere to the locking. > > >> Is this a lock different than file locking from user space? > > > Yes. A rangelock is used for a byte range during a read(2) or > > > write(2) to ensure that they are serialized. This is a POSIX > > > requirement. (See this post by kib@ in the original email > > > discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-October/004704.html) > > > > > > Since there is no POSIX standard for copy_file_range(), it could > > > be argued that range locking isn't required for copy_file_range(), > > > but that makes it inconsistent with read(2)/write(2) behaviour. > > > (I, personally, am more comfortable with a return after N sec > > > than removing the range locking, but that's just my opinion.) > > > > > > rick > > > > > >> Why can’t this tail a file that is being written by copy_file_range if none of the applications request a lock? > > > > Since writes don't go backwards, it would seem to make sense to advance > > the start of the range lock as the copy proceeds. > The current code does the rangelock above the VOP layer and, > for ZFS, if block cloning is enabled, the entire copy happens > all at once and fairly quickly (it's copy on write as I understand it). I think the rangelock holder can detect that other threads are sleeping, blocked on the lock. In this case, perhaps filesystems should periodically check for contention, and if present could return to the syscall layer to release the lock and give other threads a chance to proceed? > I can't recall for certain, but I think the rangelock must be acquired > before the vnode lock(s), so I don't think moving it to below the > VOP layer is practical? > > rick > > > As long as the read > > position + length is before the write position, there is no reason to > > block the read. Running "cat outfile" would look a lot like tail -f > > because cat would only see the new data because it would temporarily > > block if it ever caught up with the copy. > > > > tail is a bit funky, though. If the size of the destination file is > > updated periodically during the copy, tail could return early with an > > earlier part of the file. If the size is updated immediately to the > > final size, then tail will wait for the copy to complete, but will > > output the true end of the file. > > > > What about backups? > From nobody Tue Nov 11 14:50:27 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 4d5V1f6KqCz6GYFt for ; Tue, 11 Nov 2025 14:54:46 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (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 "uucp.dinoex.sub.de", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d5V1c6cmYz3K7S for ; Tue, 11 Nov 2025 14:54:44 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pmc@citylink.dinoex.sub.org designates 2a0b:f840::12 as permitted sender) smtp.mailfrom=pmc@citylink.dinoex.sub.org; arc=pass ("uucp.dinoex.org:s=M20221114:i=1") Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]) by uucp.dinoex.org (8.18.1/8.18.1) with ESMTPS id 5ABEs9J2043211 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 11 Nov 2025 15:54:09 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) ARC-Seal: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1762872853; cv=none; b=j0KTF19RnzreAWoCsFOS84VhDeHa9yPjy1XvukZDD4/rvf+f57RrbqKodwCamemKBm4bXkazjYmApKn+bLy+VnClTj7ln5SZd4ckMV/m3s0cvrYzmM1I5UBX9XC4fSak9Ba3rLvX4kAreLaRA8PJkmFBAavksw4oHuutxB29+eI= ARC-Message-Signature: i=1; a=rsa-sha256; d=uucp.dinoex.org; s=M20221114; t=1762872853; c=relaxed/simple; bh=T8srS24uX7xhDUvOPnM3ozP9Bep+EyZM4cFYsISg4hE=; h=Received:Received:Received:Received:X-Authentication-Warning:Date: From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:In-Reply-To:X-Milter: X-Greylist; b=MDV2Shyl2IAGo66yNj8ZGsMGyPUgT9853f8fbGgeSeRFLzUQDGDGW2GFtvzcRGasS3GuY8wt0f+a0FlTLQv2CBfGSLLjI2kOKvftytCpFFsx2zFdeYUOUKfmoWuy+08WvBQOVZ4zCWK8Gk1sfTPAWcPmekIby887Ec8XXTdeEwU= ARC-Authentication-Results: i=1; uucp.dinoex.org Received: (from uucp@localhost) by uucp.dinoex.org (8.18.1/8.18.1/Submit) with UUCP id 5ABEs9C0043204; Tue, 11 Nov 2025 15:54:09 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (disp-e.intra.daemon.contact [IPv6:fd00:0:0:0:0:0:0:112]) by admn.intra.daemon.contact (8.18.1/8.18.1) with ESMTPS id 5ABEq48H031626 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Tue, 11 Nov 2025 15:52:04 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from disp.intra.daemon.contact (localhost [127.0.0.1]) by disp.intra.daemon.contact (8.18.1/8.18.1) with ESMTPS id 5ABEoR1O042302 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 11 Nov 2025 15:50:27 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: (from pmc@localhost) by disp.intra.daemon.contact (8.18.1/8.18.1/Submit) id 5ABEoRYs042301; Tue, 11 Nov 2025 15:50:27 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: disp.intra.daemon.contact: pmc set sender to pmc@citylink.dinoex.sub.org using -f Date: Tue, 11 Nov 2025 15:50:27 +0100 From: "Peter 'PMc' Much" To: Bakul Shah Cc: Rick Macklem , Ronald Klop , FreeBSD CURRENT Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? Message-ID: References: <2100145914.14642.1762672441817@localhost> 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-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Milter: Spamilter (Reciever: uucp.dinoex.org; Sender-ip: 0:0:2a0b:f840::; Sender-helo: uucp.dinoex.org;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [IPv6:2a0b:f840:0:0:0:0:0:12]); Tue, 11 Nov 2025 15:54:13 +0100 (CET) X-Spamd-Bar: - X-Spamd-Result: default: False [-1.80 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; ARC_ALLOW(-1.00)[uucp.dinoex.org:s=M20221114:i=1]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[sub.org]; FROM_EQ_ENVFROM(0.00)[]; HAS_XAW(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FREEMAIL_CC(0.00)[gmail.com,klop.ws,freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4d5V1c6cmYz3K7S On Mon, Nov 10, 2025 at 12:58:17AM -0800, Bakul Shah wrote: ! On Nov 9, 2025, at 12:52=E2=80=AFAM, Rick Macklem wrote: ! >=20 ! > On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop wrote: ! >>=20 ! >> Why is this locking needed? ! >> AFAIK Unix has advisory locking, so if you read a file somebody else i= s writing the result is your own problem. It is up to the applications to a= dhere to the locking. ! >> Is this a lock different than file locking from user space? ! > Yes. A rangelock is used for a byte range during a read(2) or ! > write(2) to ensure that they are serialized. This is a POSIX ! > requirement. (See this post by kib@ in the original email ! > discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-October/= 004704.html) ! >=20 ! > Since there is no POSIX standard for copy_file_range(), it could ! > be argued that range locking isn't required for copy_file_range(), ! > but that makes it inconsistent with read(2)/write(2) behaviour. ! > (I, personally, am more comfortable with a return after N sec ! > than removing the range locking, but that's just my opinion.) !=20 ! Traditionally reads/writes on Unix were atomic but that is not the ! case for NFS, right? That is, while I am reading a file over NFS ! someone else can modify it from another host (if they have write ! permission). That is, AFAIK, the POSIX atomicity requirement for ! ead / write is broken by NFS except for another reader/writer on ! the same host. !=20 ! Another issue is that a kernel lock that is held for a very very ! long time is asking for trouble. Ideally one spends as little time ! as possible in the supervisor state and any optimization hacks ! that push logic into the kernel should strive to not hold locks ! for very long so that things don't grind to a complete halt. !=20 ! That is, copy_file_range() use in cat(1) seems excessive. The only ! reason for its use seems to be for improving performance. Not really. ZFS can do what might be best described as "block-level hardlinks": if you copy an entire block, it is not copied at all, and, also quite interesting, it doesn't need diskspace. It is just listed as duplicate. So, how big is a ZFS block? That depends - the default was 128k, but now often desired is 1M, and people are already talking about 16M (not sure if that makes any sense, but probably they will come for 256M sooner or later :/ ). I could imagine some kind of max-copy-file-rangelock setting with a default of 16M, and tunable for better or worse if really needed. But that is an operator's viewpoint, I do not know if this is feasible from design/implementation. ! Why not ! break it up in smaller chunks? That way you still get the benefit ! of reducing syscall overhead (which pales in comparision to any ! network reads in any case) + the same skipping over holes. Small ! reads/wries is what we did before this syscall raised its head! Out of curiosity I tried to look at practical size parameters for read()/write() syscalls - and that runs with 1GB blocksize, if you really want it. So if you do $ dd if=3D/dev/random of=3D./XX bs=3D1073741824 $ cat ./XX the cat will wait until the first block is completely written, and then deliver exactly 1GB. cheers, PMc From nobody Tue Nov 11 15:34: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 4d5Vvn2zz9z6Gbxt; Tue, 11 Nov 2025 15:34:45 +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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d5Vvn2JWlz3Rsy; Tue, 11 Nov 2025 15:34:45 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762875285; 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=rO6VOM1Kjt9VdGZOGOyYQCoTS3lqMOP6rQpcj3ctJHU=; b=REEKE5jgT/p8jU4Em7bqNrmbnuSb+owa1KYFdG82QMZiDowMHLqFjX+7G+MlJ7RmDzilUr M3eAVq3uX5PsEgFdiKKpHMWQe9N1s0ugQoouiIaY6EdZpI3X8pYCIj6J9YPYKSn3lZSuBn fHTYlojSjL1SVokjV5d81KxA2dEobA//87vtZkQdgu8v0OYQ79p8oQ3B8Okzbko00bKXbo peHG2BVH+2ItnQ4IcGlXEBQcbU33K6E24P1Im+SUsEi6VDKykRH68ekhUI1bYAr757OLRc qpow1sCUlB4Rn0Dmsvc9kcqOY2F8WcWuzM5ODRG13dgONkxjL8uslAArb9iHvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762875285; 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=rO6VOM1Kjt9VdGZOGOyYQCoTS3lqMOP6rQpcj3ctJHU=; b=JKMgjxULriJxZL8sAHNkA8F3KRzD/kDxVWPdEZqi8feE329hfGX487w4wttEEaQQhMDv1W LjM7n5DvooNe1LF0PNgu+enImsUiPfjPitE2xr0zI4Jw0xYncRA3VeT8lcA+c1dU8J5eQQ 7yYQQ6AhOibJmflP4m9w78ll/qrF1caKTzjKXndlPsIpwF21Hhsv2w9UgDgshEVa1sNats yWygsQ3+SulmO79R8mMnbaXQe5t3ga6lXbYzwHWEAi7LQ+rpDY8lyJKlZsFy/al0vmQS+D Sy9GgAUXKku0wTXKzrnTDO9ul1sOi4+ibRl7YIUI4UXFzCOFJlYU0R9gM6K1FQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762875285; a=rsa-sha256; cv=none; b=r2VpIJTInNwiy/bBO+wWFlogtyFHt9O5ENrEZWaHm/9xR6djuEcRG8ymkdsk/uiQVf93nN mCLjuOptSP1GXozIObFyjycQ8Ea6VQ4X4p43oG8x1r3G+AqBUeqfPddJyOxIPUwnVW7lNz 3wFyGkRjA5dAxacA9guVZXucH+pX7eBFMf65YiFSUhbQYONKud8Yr02aoaJOLjPPiFMN9u 3st0DpQ5Cr+X1mdzlAysX5+m7YglfMRtFYucn46myD7qUOoZTauEiPwbuYAJ+hZSxqBMqF p7wv+fgUNg2cVXVaPk2UE3h/kyPONS9+n9Lpjwhg0dYyvZriktl1FQqX2uRl7w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (2a01cb0585090500922e16fffef1acef.ipv6.abo.wanadoo.fr [IPv6:2a01:cb05:8509:500:922e:16ff:fef1:acef]) (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 4d5Vvn0tmCz1QKJ; Tue, 11 Nov 2025 15:34:45 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 64759A5D50; Tue, 11 Nov 2025 16:34:43 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-current@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount In-Reply-To: (void@f-m.fm's message of "Mon, 10 Nov 2025 23:29:10 +0000") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 11 Nov 2025 16:34:43 +0100 Message-ID: <86qzu4vazw.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 void writes: > On a newly installed > FreeBSD-16.0-CURRENT-arm-armv7-GENERICSD-20251103-088ced14a69b-281661.img > > unmodified settings 32GB mmcsd. > > fstab entry for swap is: > > /dev/label/growfs_swap none swap sw 0 0 > > swap in top shows: > > Swap: 1928M Total, 1928M Free > > # sysctl kern.maxswzone > kern.maxswzone: 0 > > ??? how to fix/should I fix? The amount of swap space you can use is limited by the size of the data structures used to manage it. These structures must be preallocated (otherwise we might deadlock trying to allocate more while already low on memory) and cannot be swapped out (we wouldn't know how to swap them back in) so getting the size right on a memory-constrained system can be quite tricky. If you configure more swap than half the amount that can be managed, you get the above warning, which you can safely ignore unless you either need a lot of swap or have very little physical memory and don't need much swap. See also . DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Tue Nov 11 16:03: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 4d5WYX4dQDz6Gf6c for ; Tue, 11 Nov 2025 16:04:00 +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 4d5WYX17ggz3WK7; Tue, 11 Nov 2025 16:04:00 +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 5ABG3Rc0023450; Tue, 11 Nov 2025 18:03:30 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5ABG3Rc0023450 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5ABG3QOj023449; Tue, 11 Nov 2025 18:03:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Nov 2025 18:03:26 +0200 From: Konstantin Belousov To: Mark Johnston Cc: Rick Macklem , Don Lewis , Ronald Klop , "Peter 'PMc' Much" , FreeBSD CURRENT Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? Message-ID: References: <2100145914.14642.1762672441817@localhost> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; TAGGED_RCPT(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d5WYX17ggz3WK7 On Tue, Nov 11, 2025 at 09:33:52AM -0500, Mark Johnston wrote: > On Mon, Nov 10, 2025 at 01:02:54AM -0800, Rick Macklem wrote: > > On Mon, Nov 10, 2025 at 12:15 AM Don Lewis wrote: > > > > > > On 9 Nov, Rick Macklem wrote: > > > > On Sat, Nov 8, 2025 at 11:14 PM Ronald Klop wrote: > > > >> > > > >> > > > >> Van: Rick Macklem > > > >> Datum: 9 november 2025 00:23 > > > >> Aan: FreeBSD CURRENT > > > >> CC: Peter 'PMc' Much > > > >> Onderwerp: RFC: Should copy_file_range(2) return after a few seconds? > > > >> > > > >> Hi, > > > >> > > > >> Peter Much reported a problem on the freebsd-fs@ mailing > > > >> list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > > > >> hang for hours?". > > > >> > > > >> The problem was that he had a copy_file_range(2) copying > > > >> between a large NFS file and a local file that was taking 2hrs. > > > >> While this copy_file_range(2) was in progress, it was holding > > > >> a rangelock for the entire output file, causing another process > > > >> trying to read the output file to hang, waiting for the rangelock. > > > >> > > > >> Since copy_file_range(2) is not any standard (just trying to > > > >> emulate the Linux one), there is no definitive answer w.r.t. > > > >> should it hold rangelocks. However, that is how it is currently > > > >> coded and I, personally, think it is appropriate to do so. > > > >> > > > >> Having a copy_file_range(2) syscall take two hours is > > > >> definitely an unusual case, but it does seem that it is > > > >> excessive? > > > >> > > > >> Peter tried a quick patch I gave him that limited the > > > >> copy_file_range(2) to 1sec and it fixed the problem > > > >> he was observing. > > > >> > > > >> Which brings me to the question... > > > >> Should copy_file_range(2) be time limited? > > > >> And, if the answer to this is "yes", how long do > > > >> you think the time limit should be? > > > >> (1sec, 2-5sec or ??) > > > >> > > > >> Note that the longer you allow copy_file_range(2) > > > >> to continue, the more efficient it will be. > > > >> > > > >> Thanks in advance for any comments, rick > > > >> > > > >> ________________________________ > > > >> > > > >> > > > >> > > > >> Why is this locking needed? > > > >> AFAIK Unix has advisory locking, so if you read a file somebody else is writing the result is your own problem. It is up to the applications to adhere to the locking. > > > >> Is this a lock different than file locking from user space? > > > > Yes. A rangelock is used for a byte range during a read(2) or > > > > write(2) to ensure that they are serialized. This is a POSIX > > > > requirement. (See this post by kib@ in the original email > > > > discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-October/004704.html) > > > > > > > > Since there is no POSIX standard for copy_file_range(), it could > > > > be argued that range locking isn't required for copy_file_range(), > > > > but that makes it inconsistent with read(2)/write(2) behaviour. > > > > (I, personally, am more comfortable with a return after N sec > > > > than removing the range locking, but that's just my opinion.) > > > > > > > > rick > > > > > > > >> Why can’t this tail a file that is being written by copy_file_range if none of the applications request a lock? > > > > > > Since writes don't go backwards, it would seem to make sense to advance > > > the start of the range lock as the copy proceeds. > > The current code does the rangelock above the VOP layer and, > > for ZFS, if block cloning is enabled, the entire copy happens > > all at once and fairly quickly (it's copy on write as I understand it). > > I think the rangelock holder can detect that other threads are sleeping, > blocked on the lock. In this case, perhaps filesystems should > periodically check for contention, and if present could return to the > syscall layer to release the lock and give other threads a chance to > proceed? And what is the use of rangelocks then? The proposed change would break the atomicity of reads vs writes. > > > I can't recall for certain, but I think the rangelock must be acquired > > before the vnode lock(s), so I don't think moving it to below the > > VOP layer is practical? > > > > rick > > > > > As long as the read > > > position + length is before the write position, there is no reason to > > > block the read. Running "cat outfile" would look a lot like tail -f > > > because cat would only see the new data because it would temporarily > > > block if it ever caught up with the copy. > > > > > > tail is a bit funky, though. If the size of the destination file is > > > updated periodically during the copy, tail could return early with an > > > earlier part of the file. If the size is updated immediately to the > > > final size, then tail will wait for the copy to complete, but will > > > output the true end of the file. > > > > > > What about backups? > > From nobody Tue Nov 11 16:30:54 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 4d5X7T05kHz6GgSD; Tue, 11 Nov 2025 16:29:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d5X7R3KJQz3btW; Tue, 11 Nov 2025 16:29:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5ABGUs5l024162 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 11 Nov 2025 08:30:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5ABGUs1V024161; Tue, 11 Nov 2025 08:30:54 -0800 (PST) (envelope-from fbsd) Date: Tue, 11 Nov 2025 08:30:54 -0800 From: bob prohaska To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount 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-Spamd-Bar: / X-Spamd-Result: default: False [0.53 / 15.00]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.972]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; URIBL_RED(0.50)[zefox.net:url]; HAS_ANON_DOMAIN(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zefox.net]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4d5X7R3KJQz3btW On Tue, Nov 11, 2025 at 12:45:35PM +0000, void wrote: > On Mon, Nov 10, 2025 at 05:40:49PM -0800, bob prohaska wrote: > > On Mon, Nov 10, 2025 at 11:29:10PM +0000, void wrote: > > > > fstab entry for swap is: > > > /dev/label/growfs_swap none swap sw 0 0 > > > I've not seen any recognizable benefit in heeding that warning, but YMMV > > I've two Pi2's with 3.6G of swap and one with 1.7G of swap. All misbehave > > in the same way. > > > > If using USB you could try something like (as root) > > swapoff /dev/da0s2 > > gpart resize -i 2 -s 1700M /dev/da0s2 > > swapon /dev/da0s2 > > I'm thinking maybe raising this as a PR because that swap thing - it came > as-is, pre-installed. I downloaded the Nov 3rd armv7 snapshot, > wrote it to mmcsd and it was there. I have no idea how to resize or otherwise > modify /dev/label/growfs_swap or if it's a device or a file. > Raising it as a PR because if incorrectly sized by default then that's > a fault. > > I had planned to remove the above swap entry anyway and instead have > swap nfs-mounted. it'd be faster than anything local on the rpi2b. > I'm not sure how true that is when using a USB hard disk. On a Pi2/3 I gather the network adapter is a USB device as well, so both devices compete for USB. Never tested it myself, however. I will say the Pi4 is a vast improvement. > > If using microSD I'd be wary of swap; some very mysterious file corruption > > emerged on a Pi3 which had swap on the microSD. Not your situation, of course, > > just a cautionary tale. > > It's on the microsd by default for 16:main for armv7 too as per above > > > FWIW there is a random collection of "notes to self" at > > http://www.zefox.net/~fbsd/ > > It's poorly organized, out of date and at least partly wrong. > > Thanks, I'll have a read. Happy hunting! When you find things wrong or unclear please point them out to me. Thanks for writing, bob prohaska From nobody Tue Nov 11 16:46:47 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 4d5XTg3SPJz6GhVc; Tue, 11 Nov 2025 16:45:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d5XTg0GJrz3ffq; Tue, 11 Nov 2025 16:45:42 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5ABGklC3024211 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 11 Nov 2025 08:46:47 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5ABGklrp024210; Tue, 11 Nov 2025 08:46:47 -0800 (PST) (envelope-from fbsd) Date: Tue, 11 Nov 2025 08:46:47 -0800 From: bob prohaska To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount Message-ID: References: <86qzu4vazw.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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86qzu4vazw.fsf@ltc.des.dev> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d5XTg0GJrz3ffq On Tue, Nov 11, 2025 at 04:34:43PM +0100, Dag-Erling Smørgrav wrote: > > The amount of swap space you can use is limited by the size of the data > structures used to manage it. These structures must be preallocated > (otherwise we might deadlock trying to allocate more while already low > on memory) and cannot be swapped out (we wouldn't know how to swap them > back in) so getting the size right on a memory-constrained system can be > quite tricky. If you configure more swap than half the amount that can > be managed, you get the above warning, which you can safely ignore > unless you either need a lot of swap or have very little physical memory > and don't need much swap. > > See also . So I'm flirting with trouble on a system (Pi2/armv7 FWIW) reporting warning: total configured swap (1024000 pages) exceeds maximum recommended amount (467488 pages). warning: increase kern.maxswzone or reduce amount of swap. ? I'm seeing random silent hangs (no debugger escape) but they happen when swap use is much less than half the physical maximum, sometimes less than 50 MB. Highest peak use is generally less than 700 MB, usually much less. Thanks very much for writing! bob prohaska From nobody Tue Nov 11 16:58: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 4d5Xml6fd8z6GjZg; Tue, 11 Nov 2025 16:58:47 +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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d5Xml5ySqz3kM9; Tue, 11 Nov 2025 16:58:47 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762880327; 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=5laGC2THeRKPw/GrF2thvCJbqIRHTCYM4Ke35xcyxbM=; b=Li6DvyId3J7JpkDUvhbC0A5vN5+QGNHbfsS5z6eOFGdrEn16gG5TeY6acnMgmoHauizkmP wYOWVtNHExdpLkjBPXD4oCLhbUvdjRJlYCWBlkTkrmDMFcSwG7xCijioNw7MHQWXD/QfK/ VGHYFfaAAYvXStE+ndOqoY71VJQZN+G8kesx7RDgsLbV1+tLEY6rmUo5bChQYOM5f+/Nh0 x3PxhnV3ozXNWE32UrzK+OnYVyf3VwKBnhY4bzCSDAAVE2Kgi5ROFTaEmW71sW5hSU6+JP 2zaCeZZm2rBH5bhidIUBTnsrQ4BBEXr2bJZO96JtySf4dbNUsMG7Fq3EYOf8rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762880327; 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=5laGC2THeRKPw/GrF2thvCJbqIRHTCYM4Ke35xcyxbM=; b=hp1Gp+xvOidgsMPFQ8Tlec8QjBxaA1w8hdX3gHqfQHwJ3Z3mhj6Q3tosHcg+x+CS5/O6qu uMBkClQpTeqaVNGyEif4EZi3tQBodFBWMjirGcJfti4zb68A187VUyRtyGKhfCnk21ouHB ddOJ1dxFiHllONIrUCueK4OUYAGVp6Cif1nQjzSFcuPIHrByKd4duFafATW6qHfyCL61wA zPsrbYw3wrz723A9zHiI7YWuWCArgo3hXrOJyr/O6XKKwU5X2EMFOTCr/+tWWf97oQSAFw qJaJFYrm2dO8wfsc1U55T+wsSdkPk/GN+1/H8Y9X2Tu9ke4B4xjUty14zlOzvw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762880327; a=rsa-sha256; cv=none; b=B0ONKvk0IINp9RFmOhx/sP40KVVBL/qx7lVfFOK9Z4B/auEIjWqCyb1NAoZaU5uGvkAhOS hNJeGeS3lTjv66FtobhcB2X+dYSHaPHBSCmdfPKh7uWsrmq+mWIA935NlyI1qLCb3mqkaD ih2HnyRsiouZca+vtUdu8O+wGTAACresGYbmCOBm4v+Iz/dXkwSJM9RMJjETsAmHtj6QcD ZhXhEUlVCs2A1UtnrxTXnGvM3fIiBb1csFO5Lf8hIWw9A0dpMzbWronvzvkc5fgfYNlfmX dbmKrOQA1zPeJ/PjMNCfP2QVBxkzGWGuj203XBjpiOt2vcfEFtM6a/7UPKPhnw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (lfbn-nan-1-698-103.w86-236.abo.wanadoo.fr [86.236.35.103]) (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 4d5Xml4Kr1z1RJl; Tue, 11 Nov 2025 16:58:47 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 71820A6409; Tue, 11 Nov 2025 17:58:45 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: bob prohaska Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount In-Reply-To: (bob prohaska's message of "Tue, 11 Nov 2025 08:46:47 -0800") References: <86qzu4vazw.fsf@ltc.des.dev> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 11 Nov 2025 17:58:45 +0100 Message-ID: <86ms4sv73u.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 bob prohaska writes: > So I'm flirting with trouble on a system (Pi2/armv7 FWIW) reporting > warning: total configured swap (1024000 pages) exceeds maximum recommende= d amount (467488 pages). > warning: increase kern.maxswzone or reduce amount of swap. ? The maximum recommended amount is half the maximum supported amount, so you not only have more swap than recommended, you have more swap than the kernel can actually use (467488 * 2 =3D 934976 pages) and should consider either increasing kern.maxswzone so the kernel can use all of the swap you've configured (at the cost of slightly reducing usasble physical memory) or decreasing the amount of swap. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Tue Nov 11 17:22: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 4d5YJm5Pz2z6GlH8 for ; Tue, 11 Nov 2025 17:23:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.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 4d5YJm4Kp2z3pKr for ; Tue, 11 Nov 2025 17:23:04 +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=1762881778; bh=BcpY0tmDHejiOeCNEhNDWL0igW7rb8zJk4tgnRiOyd4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=sT1Av4ktua6ZJws3Z5CDkfC85jXSgLOHYehVOdFGUw9Rd2DO+bvqyNzyPUXBtFhOrgpD3LCwxtzEGMG9++XrXSrCIFhNxGR5YuIxWM5TEdNxc0oCb9KBc93PqZwwQ/v9am5GKF/5wa85Q3yzua4SwXdGGrjV5JigB2Mi4uU+NjECDN0rGkloSMHwSGDYwGTZC7Lvrtw+SweWOAsXojAmInSWZzxBVqBxeVl6DJ6MSjHUD6meG+LNEywuX/UJZyQCL1kVI9R0gbgZ1xEGEUOrz0LOpt0hwIjtOqcr7vfDtP6lOtoa4v7DRteY+1PWKBZHFDAyY9lKADnuGm4cpp72Jw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762881778; bh=UDzB0QUivuWDhaGO1cJUm3kfcu322loy8hNU+lVI7Ah=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hKKb9HoI+c0gh1USFowS7IXtC6iLqf7Kj0qpGHmtdgEf7qA0ehd6buLXgabEBwL9rv7QMjsR1NuVXGk9urE2O3YXlJC+QH/AFkdiNrgcLNpagFEyvh+VSkVw25RdhWxFdZlB1QjTATGgVq0kAyh1RbM8syjUATkIkoKebvzhOry1d3NT/zrB18rWLRAaw0eWvjp0aurtbXwYTgjOnvGf44kEK69RAW8U10pDka5e5EihhRZ9yQy4G2yUzrIxWFWGc9/voYkuFeNTNcb4aWrNRMEZ0WRVksIm5H0GgLpoCu6DC/MyZr4JZRKIZyUU9a9fOQPMnyIxEkA2iiW8umVVXQ== X-YMail-OSG: e3HF0L0VM1lIXQ1PAcNYhk4mkiP0G.JZlooqVyKj3zMYTyjbcnzKZWOIP.1wTw6 hDk.RlyMiJxqzce7ZvHQ567xLXQOzni0Pal.O2zHt2G2OvMeg6LHrcJoyMbFOFFUe1Xg9bZl.pFl rhYeV66kJfbxki1I64GzOL3mgW394hdbjXdb9ouHbv62fpK.vFTQuIUEIkdaQ3fcAxk1J3aBFTdQ 1IqdCimR80FLC6RgiJ77900JPgXjYCHQcTPNoPKHc769NqY.G4YLh3gH.pEoxyFkiJohdO7eA5yK ZAzkWCO2ufLKCW4VI_PcwfJgWKRK5c5OHU0MbjPUAgeAddEr.fKmzzYLaoz5tLE0MOCjiuHKDW4c XoEEqfl8MddmkL9izoMc9tFp7zvtNC.yB.oGIF6fjX7X.3XjTBNQxUUNAVDdIg0QwKvUY8.pjCp. 4pS22tK6FejaQXaoBAyBEmTJXzepnQ1X3oB5MLywndZSbvDfqWddsQQcrez881TYX4SkqY9wc0Ow jvZ6IMI2dQ1vxwiZ1AVXQX7cD5cqPkJIOAsGyn_KlyRaIXt3nggneckwnxsE8hIQrgZ9Cv7W3lC. 4j7iVX38u8RisbYn.CxoHZ2avM6zlbMBE0SOTmYUytczZoC7bWJNXoQ0nkxiUB134SSF1Gs6walW ym_Avic0v7T39KV3Las8YgtfOwRxS9g1aW5CXA1peaDemiDIgq9_VkzdJvtnP_IIrApUT6DptjFa gwi_lNI3QRnm6nx71.lvYKjm7rpMWXoIXpXWjB6wbajsKf8SEE68sbuBYYIYYKPjF2A21nZ7OSva rlg85Jsbk_khOHTyBygXPK.komMaM7r185veMda5raZgjFN9uupKN2ApmOy0pfXrD8Oj_FWeMeMe TaY2AFLDXNnPlamTKCe8hoeqOJrs17ZK_KeBhl3aOqtVcLuRWhh4thDHe5zgtp2SQ940ZWkX5HZp ma7KcHuQnPgBWdiX0c60Gw9OJ9GVH7x2fv9j4_a7UYTvuLbG44.3S7uAoa2RQJe.jY0xcSHapRdc QRDpJMa5rGeZwtWtNb88k3ygeIx3sd2IgM0uPWZ5a81fzrSDC4_JNI_aCZR6r1mP.ANDqglQ8VIx qGuPxT69yDWik5u4XTwF.GVnMb.YWAYr.TfFkxRM35EbjS6g.eN7jH7jejGoDzNJUhyLNsmyNM12 RWiaINCrBCeUSHm2j5XOTK2iWG6t1mCSQeE9cZWIuFm.X2Niy_iaZgDJ6T6siCW9xv0tU07s47Mn zuyK5yirkHEUcmCBbxm_5QS7aCwcYnP2yugNtGjB8Qrw4QhugoncFucDlxCXdnHPrC1RKDeWtMta vYXycFD0YJaTtS1ZLCq8q_JsDOztD8NHsiE43c._7YrToE9xbI1_dQ7qXvGBApl.ajpFkmNAA9yw Samyn9Nr3x2zflB0P3TI1RziqRWYYEyXtMJOHDsIjNyVfWC51nBuGukJU68cegHP4dbpmPxHgnw_ amRhE9Pca3z7IsFqjkes29pqjj3ZeUsnKssTZ7zs.5LqAsaZUzdMN7wBF7u.x2Vb0N32DfHogeR1 FCiP2Z65u3UBFCNQkJwKgKd7YBGD8bwefULowlfvdZ2kl0buwS0KJoz4Odf.gDGkVpcvu9.6TRdM 36AxeaXqv0OleflKQaBCuYHN9yGK18KrmyV4KjVbvXfb8Oe85WHFcDSzc2XRuoNCyqyFy.OWwl.A aJauSJXtZt.7n8Qn3rZCxge06DYIRZxSzjxSjcdsJiSkvM4.TU9AcNXgtsO5fkOQO5dhVIWDD_PO D8BmLOAP7myLEueBwhoQhnLMDSHkJ2W4Y7g3xTOL.daffGEaOTUcGtQkdYJ9tMXO9Jv9VBt6xXuv 0ijRoqOn4v6EVkBpIBNNLOfJiBuVczy6.kwl5xXWI0hsFz8k22jcPQy.CSQYHWkVkqwWdsynTKgj DZZKFpCBkL1GjazN5Df66xu25VlQc.sAf7xjttsg71UQtSnEhrqsZgVJXwgbXSk5ffWTPc.J8eSL zpaAkYDVvNjY0DUeVTer0V9UtJLtduTr1h.mCLDhTP6d1XMIR13OnwHy4wmZzrlRO84N_GwMUIHc uG7kK6G_8cCrhfytCbVaIvufLwxKPyNHciFF3Y_6siHV4t269LedkEPooedZyNS5yUOnA9_IQonS hGEOs_0y5C1CS1j34dtR9aRY2fNHfR3rZn4VhlOL9XnFuHSGPRRKo2X1JrKWGQRbouFdyzY99C1q a6SDb_FWLY8qSvJIher8mSm5jblj3T4SbOe1ZOCt3QDReA6sFD30g8GHMwcicmc7D9qcPN7Knlkn w1XE- X-Sonic-MF: X-Sonic-ID: b772c60f-321e-41f8-a8c8-02ad75693e91 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Nov 2025 17:22:58 +0000 Received: by hermes--production-gq1-86c5846576-7pcnc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 09bfb9a6e8fab4c55f72e15a5311dc9a; Tue, 11 Nov 2025 17:22:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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.700.81\)) Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount From: Mark Millard In-Reply-To: <86qzu4vazw.fsf@ltc.des.dev> Date: Tue, 11 Nov 2025 09:22:45 -0800 Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org, bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: <59321C66-9B02-448D-A275-500857BEF641@yahoo.com> References: <86qzu4vazw.fsf@ltc.des.dev> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d5YJm4Kp2z3pKr On Nov 11, 2025, at 07:34, Dag-Erling Sm=C3=B8rgrav = wrote: > void writes: >> On a newly installed >> = FreeBSD-16.0-CURRENT-arm-armv7-GENERICSD-20251103-088ced14a69b-281661.img >>=20 >> unmodified settings 32GB mmcsd. >>=20 >> fstab entry for swap is: >>=20 >> /dev/label/growfs_swap none swap sw 0 = 0 >>=20 >> swap in top shows: >>=20 >> Swap: 1928M Total, 1928M Free >>=20 >> # sysctl kern.maxswzone >> kern.maxswzone: 0 >>=20 >> ??? how to fix/should I fix? >=20 > The amount of swap space you can use is limited by the size of the = data > structures used to manage it. These structures must be preallocated > (otherwise we might deadlock trying to allocate more while already low > on memory) and cannot be swapped out (we wouldn't know how to swap = them > back in) so getting the size right on a memory-constrained system can = be > quite tricky. If you configure more swap than half the amount that = can > be managed, you get the above warning, which you can safely ignore > unless you either need a lot of swap or have very little physical = memory > and don't need much swap. >=20 > See also . >=20 man 8 loader_simp reports: kern.maxswzone . . . Note that swap metadata can be fragmented, which = means that the system can run out of space before it reaches the theoretical limit. Therefore, care should be taken = to not configure more swap than approximately half of the theoretical maximum. . . . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Nov 11 18:24:47 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 4d5ZhM29zbz6GqX4 for ; Tue, 11 Nov 2025 18:25:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.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 4d5ZhM0hZ2z3ymm for ; Tue, 11 Nov 2025 18:25:07 +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=1762885501; bh=enIAF684M3hPyvSu4jN+LRuohBBJjfPYPyna4Gmp0TA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZaOchJ5MwUd81YJ99PJCyBYaPQtlmdEDkOEiqnCiwdF/H6Bz+x/YaWD/oIjWdsELW1UPjhCyXSBmT03EY3Ks5x4Ky5tsxaQshzghkGC5TBCssiWsIvBXpJAIPE/08Ho5bcIKlWle/GsTK9Ozi265JFogGksLrLdL/uOsIxsiNqSC/lQQXlahEvmBes3oH7zNICJE8JBfxPNDKybgl8Rbg+K3FeCY7qo14LzLuWcrCctYq00Aiirl2SQZ/VJhZaghOtPPcOZcbzmdWe2F6xRFMPIgmdFjMoLN1YMCJ2z4L6NVuGDGiT4yOnYkVSvIAadvyHspigDjlMtlJaUb4+aZnA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762885501; bh=j9ea1B566XqUA50erQxAtdg+EjTlzdsut0SN8RKLor+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=I4hOF+zIQftenYzSZGEJUwQ0QwDLEBAn8T2HJ7dcDtBYe9tl9GuNZsLgbvxrEHhW7FFqAJqit/BIUqdYXXAOgsTeXjCBjPFXU+KTpfWViASzp7+rAOQLMAWVN/krWT1ca2B6QFvWcS9KZ4hJViImmIvbc5GXuxRWliZ+XxhfvFtjvSuNXX35U9c29HlVa9IMpp1Yh1Fg+4o5DX+T7atiT8JkHf1SNpbYyrGsUfkRinsroROo7b1MZUogQQjqnq3lRHvFJyd1LFbHycm5E7U3GNz851ExLFz4kZ0hoRuG6eBBXhLXNSKjHOxHNvLnJusxoqbGRoD4YriC8SeJvDASmg== X-YMail-OSG: 1GVLkPgVM1lWCW9r0lnRXPF81pCOjHejR1B.wDHQmwY41K_1BV6g0b8pwhwYFB4 eaKhK_wT6fBBJn439UyRAe4ZWg1zVzHye6Dpt5Ssa8gnsiQTdrujBOoWbKbhrMUxiAWq_.wQPmdz Oh8uTIi3gEj3GzaNUq1H9FzVStSoTqg0oVOUN015VX40Xi6Io5eKK1AfsgCanzwh8OFEcX.jyfZM .Hst_FTshtrVhA3o4ujs_S.Q2UVYEdSzLyutuCKN3uJitKdbVGFDbMEN91VhKcrM4Cbc43HHZ0it PyP.Ula1R1P0fgfaSDayM0DWjWqEIYA4ZvnSLHGxjc6CXnfUsZ_fAAi_m78faU2Z1zeRa2rc60CW YHHFIx9gxVBbYk5AiHjbYJnlO9_LWpuIJZ5qtzcFmNqIqc8TEvpf6OLd8BA07g5qHFaPd7LINDeN eEMl5c0QEEEOstjm4lGBM_H.7eF2766eiJlYHNKdbEYtpJjXIS1EhkGOuExUo9PM4Y92e3fECN_. NPu8c8FzTkN6..8_WmgAyWCNfBXDNN3z7YSpgYuZwFfNR0ATYjoaOuWWDoQh5KkQD5v0ehXP7fCC 0mBHYgw972x56KpMZoxwAcxYspOKxGiWH8nAWaZBWryBtfkvtAfhLw699.s.6Iuf39cUyxNY8o2q 7mzWRXd3B18ioBC3dXruicSrThmaQrznVrEPZnq2UZFWUEmS5EE4J9BTqSLIkwcsxOpYzmxch626 H7TYPp9RqRQKP2p40U1I4Sd62lZgMSVZDDg7HQ1eq1wDVY1bAJDOsnRSEvm55xWaH_DtKtsXBw_b 1OXyDuBQxHLHLTItoyadUwmjtt2rvIYLp92Bfui1QNXX4VoPbjcNgMhlFTOt1TSNZuroCV3JNsvd 52Y48ahYWEpjG7g1.qWKNEyhU2Pr_ubqo26oXfbnXvgR16WJXGVqIGrioftVKTW7_Dpw_X9J.Kth tRvtfFwZqPEkybaSOA1By8IO6mRu5jpkXapi_Zw.lQHv2.Au3LIOkiDwDg8osnmuC5.ZJWp6ThUc r0vmG06XYeudEry_mB8k47sSHDUWj2khZi.XcrYiGeXx1fdcr6cLVOr0bxz6cfzCC41xcvzNjDH3 ViornpfTsJXNWisIxHU_p_QXoqMfsBD01UksvwfQHJKpnh7qJg5ONUiTfZZwlCwoJoD55HtMUJ5F OBXSpjt04PNeMR1tYL4lk7IfyTOpIgaLxDXw2JRbmbQomVEzNLCBUjYh8N8iZgLYUi4Jflz8JZE5 Cm.5sP2qsaNRw7RItkNnW7K8WRmx1xkoBXrUpkDEgQUIJHmfzlkz2eoK8KClg_rFJrhuY.08lol3 3wenD_94FEPc91nHpj79WO7jdY7pKggA.QJM.ZqpBru0lYqXehZ7fnWkEUnZEarh9TJKfnNa9L8M 9agMTjN8S9oBLw2hcUvRmxmz2YaRvPtUOiSe9ihqS6FXdlLCnOiBWaMcyZ608z0uzvRuAxp0XY_A Jw.X0FM6wgsLCaztnQDTcdWqghJQLL0Mvaro08UQv0YUZ5.M_vezWSHQyois3_8DtGys0MXbjjCu csco8YzC2FsJDFbmcgYOOB4FCbY2JHRLFr85LZonBUySFTjxjMq_1ODG7sRZwXh1WEEcNo8raJ2R 042ybJrFONKpruCSdN2vOFBip1ys10BSQxmxLhXh127gO3zlENpvT4unPRvLpgXUzBytl47w63bB Lwxx5L83osaNhE4Gr6yZeg9mJ_M80XsQZgQ0jXKgY8eXlcyEzX8jc05S2Crhe_4NZXneJ_x02fcC WQ_7_nA_B2M9XzS5t3ehO7ycQh_F9Lr0jtdBCR8QDZPDzC2RaUlU8NGi7PSLi5OgHZfu6xCr0BrE 7yJHX5d8_BOt3YWp7.LYgP_jR2jh9lFtccsIR9Eh8vmqP5HJDOA1V6dc1iic_v1a8ttYNMbCfgdT .XyaZ7aLuDJzBtgwpUkUgL2FbkP_1oujWYqASTwF_IHZR_a1tcsb6e939H_V145fhPrrN3UsIZ.V QIT.WJku7qicbNP9vJyUQESilg.Kvr0WHvG.F78upZuGMuIb48GCV7DBRlzEh0ZFe.Y7dhwSAdbR ufrQRXzYylU9m9vlHs2CuUw1Jb_A9SOpoE6GN0c6tO2sYCb6dk.a1HzQq8C0nTk_7j_A291E0VlV aX6uYA5IVmRgp4MeeuZsOxby.6Ay5dVilaJ7YCcB13nWp7ZAd_bC0Ds_L_.k3967Bu7pYppyyM0o AH3lNG1hOIrgKHzioOub8LZ6pBX5jtg_aYsrAK55710hAOLdzdJlAAMBp3yE7A0TtBWb8uPsvD0Z 8TgDhEw-- X-Sonic-MF: X-Sonic-ID: d09321a9-0f90-4fa8-b290-1302364caacb Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Nov 2025 18:25:01 +0000 Received: by hermes--production-gq1-86c5846576-4mldz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9fd0a045fe28989fd439c03eed71057a; Tue, 11 Nov 2025 18:24:58 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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.700.81\)) Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount From: Mark Millard In-Reply-To: <86ms4sv73u.fsf@ltc.des.dev> Date: Tue, 11 Nov 2025 10:24:47 -0800 Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3C656BFD-BDBD-4E83-AD62-9FBDE14A94D2@yahoo.com> References: <86qzu4vazw.fsf@ltc.des.dev> <86ms4sv73u.fsf@ltc.des.dev> To: bob prohaska X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d5ZhM0hZ2z3ymm On Nov 11, 2025, at 08:58, Dag-Erling Sm=C3=B8rgrav = wrote: > bob prohaska writes: >> So I'm flirting with trouble on a system (Pi2/armv7 FWIW) reporting >> warning: total configured swap (1024000 pages) exceeds maximum = recommended amount (467488 pages). >> warning: increase kern.maxswzone or reduce amount of swap. ? >=20 > The maximum recommended amount is half the maximum supported amount, = so > you not only have more swap than recommended, you have more swap than > the kernel can actually use (467488 * 2 =3D 934976 pages) and should > consider either increasing kern.maxswzone so the kernel can use all of > the swap you've configured (at the cost of slightly reducing usasble > physical memory) or decreasing the amount of swap. Beyond the issue of having more swap than can even be used under the best-case kind of contexts, given other defaults in use, there is the following documented property. (In order to put a copy of the below note with this other related material.) QUOTE man 8 loader_simp reports: kern.maxswzone . . . Note that swap metadata can be fragmented, which means that the system can run out of space before it reaches the theoretical limit. Therefore, care should be taken to not configure more swap than approximately half of the theoretical maximum. . . . END QUOTE This means that using more than the 467488 pages of swap, given the default kern.maxswzone (or vm.swzone), runs the greater risk of having fragmentation in the data structure lead to running out of space before the swap space is fully used. But another paragraph for kern.maxswzone in that man page reports: "Running out of space for swap metadata can leave the system in an unrecoverable state. . . ." However, if I remember right, you have reported testing with the swap adjusted to not produce the warning --and still got the status of losing control and getting no more output to look at. If so, the above is not directly a solution to the specific problem. (It still may be a good idea to not be oddly configured while trying to find a solution to your active problem.) That paragraph continues by mentioning other tradeoffs related to kern.maxswzone adjustments: ". . . Therefore, you should only change this parameter if you need to greatly extend the KVM reservation for other resources such as the buffer cache or kern.ipc.nmbclusters. Modifies kernel option VM_SWZONE_SIZE_MAX." [I wonder if the "only change" wording should explicitly indicate a specific direction (increase vs. decrease) instead.] Side note: I'll note that FreeBSD updates can change the detailed 467488 figure that is computed some. Using the exact figure can lead to future warning messages. Leaving some margin for variation can cut down on this. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Nov 11 19:03: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 4d5bWS02b3z6Gt7p; Tue, 11 Nov 2025 19:02:28 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d5bWR48FFz457V; Tue, 11 Nov 2025 19:02:27 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5ABJ3Vik024515 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 11 Nov 2025 11:03:32 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5ABJ3VnN024514; Tue, 11 Nov 2025 11:03:31 -0800 (PST) (envelope-from fbsd) Date: Tue, 11 Nov 2025 11:03:31 -0800 From: bob prohaska To: Mark Millard Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount Message-ID: References: <86qzu4vazw.fsf@ltc.des.dev> <86ms4sv73u.fsf@ltc.des.dev> <3C656BFD-BDBD-4E83-AD62-9FBDE14A94D2@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: <3C656BFD-BDBD-4E83-AD62-9FBDE14A94D2@yahoo.com> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d5bWR48FFz457V On Tue, Nov 11, 2025 at 10:24:47AM -0800, Mark Millard wrote: > > However, if I remember right, you have reported testing with > the swap adjusted to not produce the warning --and still got > the status of losing control and getting no more output to > look at. If so, the above is not directly a solution to the > specific problem. (It still may be a good idea to not be > oddly configured while trying to find a solution to your > active problem.) > You do remember right. I have one Pi2 with a USB hard disk which does not warn of excess swap, reports 1.7GB of swap and from time to time hangs irrecoverably (no debugger access) at least a couple of times during buildworld cycles. It's a very slight outlier in having a USB2 to PATA bridge instead of USB-SATA on other hosts. Your point about avoiding misconfiguration is well taken in light of the fragmentation issue. Thanks for writing! bob prohaska From nobody Tue Nov 11 20:12: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 4d5d4C6m4Fz6H04T for ; Tue, 11 Nov 2025 20:12:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 4d5d4B48vPz4GCM for ; Tue, 11 Nov 2025 20:12:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com Received: by mail-io1-f50.google.com with SMTP id ca18e2360f4ac-9486d008fdbso1185239f.1 for ; Tue, 11 Nov 2025 12:12:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762891945; x=1763496745; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mbWkgx/2yuVEB6LpQVtxAau0R4EOSAnoUnjyk5bqxkU=; b=BjxZZpPKmO9zx4UUYPuq0tauHPciJF5vgHeVPmGDpmjOnttkZMrs/weUyVAQJaSCmS GcKyZqmy2KTQIwpVa1SC0cWVpKpY00v51I8LPFDOVD/2YlmhOXPfGzB5beLBEXsQxXgk u4z7j4pHuhbBI6u1ohNm/kQpKEqaCpCgaFoOj3JsmQsPczVFjq7JaoHKaVeOMbw31zF4 aD1bx0i6+wBotHheM91/DHuyBtDqlkRUsVVKWwm+6c7bwLbhrOSyzRxmLsjFnUumOD5K N2KVFcgnU3mL2ExP79RfgdZ/4T47mypyx3i9SlIfzZa4Wu39Cp+/5T6zoKevmWtZOzHv Z3uw== X-Forwarded-Encrypted: i=1; AJvYcCVxyBz3A8Hn7QgVDRKZKwp6OXQq7O8dgU2DdFguEsxeSCgyjhaGRn0wkO2IEkdw74LEfOV4rcEN/Q6YK9QcEhc=@freebsd.org X-Gm-Message-State: AOJu0YxIjQBAN6o4fQygUV76Va5ILTx/F7PGVN0nab6/69CQ48TamgxF DwM1BW1CXdl2naVfVLkbW/2Bp5K0DU6w5PM8oyieOVnJsFD57z/pRhxtJfFqWn/h/u+2iXnF0NP FGb2ihntmcTtyiIpcOtDs8L/1fBJ6R5k= X-Gm-Gg: ASbGncuLi2Wj0l7HbODIJPTVXo8m8V7SXampOEPsEwe3g8EsH6osjBvNvSLLa/x/A1O +NYvNa2g3zbWQT321j/0pEWhvIyN90X+AO1bIsn9HmFhM1ryiv82xFve5hoVhtlRQPvhSQe/Af2 WtTFMbwgrVLJAsX5/3vJfjjm9zX0N+NKDTUnHtCnXF/XtEBSwF9UPobYTNhVHPJ9ZOQTW5JWG9G Z18itAto4+RbN94masOnyBscgMgujJQV6vWaenimhu4q44Qpuj7C25Ec+uBdCK0e3EmbJ7Sqi+k tIFSpbKIPAfwnazIyXU/KtlJXaI= X-Google-Smtp-Source: AGHT+IH4OS+c0LxgGwPlDUKbVThjEfqQ0J2tg5oEl1Y9V0rgAAgHwLwQdn7WrA7y3ZHSJJ6szSkUL7XXVlIQWo+otLk= X-Received: by 2002:a05:6602:21c9:b0:940:e0bd:ed8b with SMTP id ca18e2360f4ac-948b6f81612mr403628639f.0.1762891945233; Tue, 11 Nov 2025 12:12:25 -0800 (PST) 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: <288036F0-180F-4DF4-94FD-66365B7504EA.ref@yahoo.com> <288036F0-180F-4DF4-94FD-66365B7504EA@yahoo.com> <255c624f-765c-4091-b3a5-22d439d292a1@comcast.net> In-Reply-To: <255c624f-765c-4091-b3a5-22d439d292a1@comcast.net> From: Ed Maste Date: Tue, 11 Nov 2025 15:12:13 -0500 X-Gm-Features: AWmQ_bmIIMEcInHDhL61_shCyDp6rXK4eQVYCANB1weEpz4P3-5e9fpMwuBDErQ Message-ID: Subject: Re: Backout git revision 4179e6b78297369f [that is also stable/15 and releng/15.0 as 62c3b77d1d10] To: Steve Kargl Cc: Mark Millard , FreeBSD Current , "bz@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.71 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.986]; NEURAL_HAM_SHORT(-0.82)[-0.821]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[comcast.net]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.50:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.50:from]; R_DKIM_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4d5d4B48vPz4GCM On Sun, 9 Nov 2025 at 02:01, Steve Kargl wrote: > > It's not a big ask. Either back out the commit or maybe, > just maybe, someone can commit the patch in PR290432. For current, reverting the commit is a nonstarter. In PR290432 I don't see a report that WANT_NATIVE_PCI_GET_SLOT fully fixes the issue, just that it fixes the build. Can you confirm that's sufficient to fix it? From nobody Tue Nov 11 21:17:59 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 4d5fX32jW5z6H35K for ; Tue, 11 Nov 2025 21:18:11 +0000 (UTC) (envelope-from kargls@comcast.net) Received: from resdmta-h2p-547626.sys.comcast.net (resdmta-h2p-547626.sys.comcast.net [IPv6:2001:558:fd02:2446::e]) (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 4d5fX26zhPz4MRR for ; Tue, 11 Nov 2025 21:18:10 +0000 (UTC) (envelope-from kargls@comcast.net) Authentication-Results: mx1.freebsd.org; none Received: from resomta-h2p-554994.sys.comcast.net ([96.102.179.205]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resdmta-h2p-547626.sys.comcast.net with ESMTPS id IqSvvr4hCLJ5HIvkYvtGSH; Tue, 11 Nov 2025 21:18:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1762895882; bh=CaYhmcpsCFtxpX87I09wszFtXtuR/S0d4g/NTZP5Dv0=; h=Received:Received:Message-ID:Date:MIME-Version:Subject:To:From: Content-Type:Xfinity-Spam-Result; b=RtLCHWbkwIv0vh62P44aVGto/D+3SBpULd49d3bv3sv6avwWVy/2TDKgcpn3a5b1n bIdzJkaYA7DYPMtb3LeB04xB7MfpRF9SiFw90zgqZCYgnEoaMvVxlSH1gI1FcorZgM YDVnDMpaQPtmx5ETQbVO69FOWI48WC68T0zhAsEbh+BWeeZLyQ1YSwTd/nCrN2LoQy mo/ARloPdCyGgSh7LQXpTGUOcMFC/E4oUlWGROT1nTbbkzFtCB8RTyYT+i0JosUmhp Jz9/igEK5aedhzGDDiZiaoYRv/ztSHihg8MyPhGZb4R2GXemwUOQUT9bTHIUiNOuw0 FrcTpNbKLPAeg== Received: from [10.0.0.30] ([73.83.213.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 256/256 bits) (Client did not present a certificate) by resomta-h2p-554994.sys.comcast.net with ESMTPSA id IvkVvdck1pi8UIvkXvOSbG; Tue, 11 Nov 2025 21:18:01 +0000 Message-ID: <5c38b898-3b3a-43c5-9e91-5e313f978b2e@comcast.net> Date: Tue, 11 Nov 2025 13:17:59 -0800 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: Backout git revision 4179e6b78297369f [that is also stable/15 and releng/15.0 as 62c3b77d1d10] To: Ed Maste Cc: Mark Millard , FreeBSD Current , "bz@freebsd.org" References: <288036F0-180F-4DF4-94FD-66365B7504EA.ref@yahoo.com> <288036F0-180F-4DF4-94FD-66365B7504EA@yahoo.com> <255c624f-765c-4091-b3a5-22d439d292a1@comcast.net> Content-Language: en-US From: Steve Kargl In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfLuvbUeua/gXiQNnDoih4n9Rne4tLuuhI7+SlNyuq2lbX/HYl0FIWu3ae0FZ6doW89p2NBXqlcHPnm+vsmtmbEmWiUrR21CI2CetAvS+/VCchuXrBBQL OBRvIdlN16oLtdun900gB6rBURt6Liky03QBmkV8IqNs68DtWG+bt76BbleFlAqwpBmULmddj2xw0gHcMnhyNas8e7/uyTizlNGheyJDt27vVTRFulK9Qc7e bvJS4SSjXWqV6y0U2mR0XSfeSuN8Pf7R31uChNb/woA= X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d5fX26zhPz4MRR On 11/11/25 12:12, Ed Maste wrote: > On Sun, 9 Nov 2025 at 02:01, Steve Kargl wrote: >> >> It's not a big ask. Either back out the commit or maybe, >> just maybe, someone can commit the patch in PR290432. > > For current, reverting the commit is a nonstarter. > > In PR290432 I don't see a report that WANT_NATIVE_PCI_GET_SLOT fully > fixes the issue, just that it fixes the build. Can you confirm that's > sufficient to fix it? Yes, it fixes the issue. After the build completes, one can install drm-515 on freebsd-current, and life returns to normal. IIUC, bz@ indicated that the patch may be break stable-14. I don't use stable branches so cannot verify. May need to use a _FreeBSD_version check, but I have no idea how that would look. -- steve From nobody Tue Nov 11 22:09:23 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 4d5ggW54tyz6H6Gr for ; Tue, 11 Nov 2025 22:09:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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) by mx1.freebsd.org (Postfix) with ESMTPS id 4d5ggW0HYtz3Fbn for ; Tue, 11 Nov 2025 22:09:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=AUAUqXWi; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762898976; bh=0fZp4MZW7MQEFjMDFMT7oz/or7yhtf6v3ZY5qolb7Xo=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=AUAUqXWiTCvVLcgWhen5VJoqjr/L2U2L/lox7fuUDy8zCi/7e9NtvSbZPPMBZJRzYF++0G4rZ+92Mx2ANW31fxD6T7U1sAahP/d5pFsyaJNq+JUg64LodNEWyRbbBC8tDbmiLKVJsh9kStB9aW+g7uKHLe3VUAcPlya8QISm3qi4jZAytIxFFWRLCDWpXDTqcsTATh5yl1JixjX6dKC2pSgofQ/kknDJ86Qpbzwpfd7GKbCvneTGiG0s+QNfEhY9YF3vOiNtLs3Rx+22srKNfAzLiznXyNaLidhgm6d+EyFndlLcQM+KgGgf/y4aFcXrdDGcgxy7ToKTrCf8kVuRdg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762898976; bh=xUgsGmZqEFbp5RUIbhugw8KssyhIbMxL7TIaEdbAmKe=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NfaMY6nw+lQPpChUx1j5gyHSw1G6V6BWm4h6QkC1wbw7y+YUuyTtd1f6HQPB174jIaxWWHby+NDIF7swPbs/Tzj8G5bNxQR3quvckdF/zjTQhP3wBMCHTSUIDHy9nHatwCjcAnPUBLSulcah+EB0cxhsLSUKAEHXaYfUjgFfLX4js8dmkxLtf5naRNCCIzH76PTRQmBTt9dEJ9V/LWErAkXcyg5OvaH0Tqz0WCrhS+5D/mQsXagrK1Etd/FTb0hfYkm1+d1SfjXenwvkqF7iAdXv4ixOxyGUTxW6OsJZbgD5ljNyTN9atPPj2qp3epC5e5wC+IPhyWwa/JV7tRfQfw== X-YMail-OSG: 7sJxFW4VM1lAYE8O0qkmhpHlfAIt2nm0hHckY77_Xu1GKuw1aRqEGwgUCq9DDnK hSmL_DjORjrLf9QxvG2lWoiuwjnhZpv_Z1CHCawLgAkvctY8IvqSW_MbUBD7QnOw1XBb3_I9jTuJ Ouzy.kUYTuB94wQ0GnbqNZKVFJdGHFNxET7aNsVOY8C4LKoq5t9Iy54ucOOKJ7AAWr87fZjOC4tW BoQWLdkCAtOMI2wzpdc5HYUsKoW1RfJOREJJLBNrl9hHEF2ape6jhrn658LN012BFihdLGyQzHq5 zXIQQ1cOrYxuSgKwH_9y5FQs6uRzzrUHVftaJXxEcmAdNnfymxzzemwZ6.0RgjcTv3idh_IIRkG5 gK0Rr7hIuvJSaefoKXITDQm64ilMWws.6M8V2j2aXIy7wK1YXLLYUtFP0HWKwHL_d6a.7V.8WgPi m1B6vJ0.mDZ9Dh68vnynpbUi_6Hw2ZOGivgB3995dsb_1Y7i5DQB64vELiTy_wH.sL8Yytf8bh77 dL0ZMJrIDHZMviFo8ey_OeShcJl3rQ3YLUNLYOgdzJSQWE0mvuD3DegNM17O3EPE5evNeFWWEsuS kPlhdqq6wxc2C8chokYuYnai.1h.yD4P_QlP72rPF_DTf6_crYuJuAYYNUOmmWpOUKdl5immdXST EIH84Jr6ADNm.2KHU2yu58JsXSGWR.Qzs0J.OAqE0CQ8aT6kmEmG1I05LDmdhPJKTXglFSi.U5Z7 7XFHG59o5rSex8wDFJhNylGTEzrsQ0RKoxB2Zd3wcrcrH.t2h9iqJdH81bEt3bEaLeqHa6lhYpi1 9abnRefRlf9Yvk7QutIHcHV_MxE1aq0S5dCMF7ESi8doZe.JDGs_uiUHZXcCKcgJuoqEC_egKAxe 1Yvost3IcLctB2RB4kf9J7Y7jXMEahkuSePDK.lDgp73NDxla5av5KKUBoardvJl00ku3gzxmhJo 0_CcQ09ZJ8tn1.roCWQrRBV3RF68Uo_u6EoKMlmyEHaT7TPPnHinQ9gngSMBS6Q3Rv92VGL5EJOM utU9sqIzdVkzFeo2KwwxrRq7wASwF_DVDK_wLMU8eYGMkCNWPk.IY0MbPUs9CdoL8JtEC5e.j6L9 iq34wKJixXHdKoVpKLrrFT6jofZ9uo8lXyxWo4rHz7ZIP3B3dPud3q0p8W_RnCR_Un7QyD7o5bit XJI7M0Dy9WiW__0Sg9qiCIFNgb3zahbqG75Y8L4nwuOmfYKgzAM.RUQjJemuqby8h9ybkGSisaXs .LGOwP_JUDzkx5TPNfkYI0eQYjTwjCc9emo3FX9S4TJxmK3S52HKnrwqu8dU6eibAE3MZECy3ZCO Jw6ZFW.gAHq96LDmrWPqe.H07y2sXehFirdM7NwpOPfM6guqEEXk92Jl.uiinutYapKggHk4QN6H gMy2hyPV_cHIP6RZndwLi4tWE_d.UhAZUFta.yKfmZVETiQKXhY.aO0EJSEDC5YONNdVBRmHP5bj _C26wqXan.scbVulC8jOoksGjQMiYHWNiQ4Kh24u2KBipOIsv6Oz0RwliTaZH_JsamPOY.0q2ZZi 7l6OiShev5mLMD9GNv6mpF0djdwGiEcLeBnwsCBn6gyEjxlwAZG1W_i2K5zsU7YgKbPn_hSAQvU9 Dqly5PcPqjafNsy1lLuly5hZ9czbek.jiaWXrdihYi5zb_ohwW9dsPqdb4.GvLTh3MrG1I3.Njb8 RgWOL4Alafu8iOJKnYpR.Ce8PkrM.jsJEd_7gHIqcKnQFssfFRtShxXbxJvIFFTL_3INPhtjiKb2 ssSk0phWhIKNtTWtce9tmAre75ATkljnEC40ueuOEQM1swRUWkM7Oq7f8WyXYm6Cb8eDrSV379J4 rkIdTZOI.Zmm99NYEfJfKudpoQ5YRAeBpWv6CwaIh7bSjF1QjvdXlOtLoCWuSjqIfPcRKHZBend3 6Dijgn0fsEwQN12UwCtHZs500VB6zfsOj_5gorQQS6EJR.Bkr0kY6SnENUnRx11874cQsJlwsIoI 2HLjDH9bRh75RlA9N7602uD_pbQFgZ_cU_QszBjw03yCZFzyicga6wcTHmBd.SubjkCVcZwaMB_9 .PrnL39ODVNymBNFOmibNVrVMsyjcuKtto4SOWNFiLO5Nlopo79of3kaubauaEoiqELfaqc5tUxv f0uO4CkpUN7lv0EoaajzLdr87BpepCsVM2nk07EK9QbM2Ia5awKac_qT09hz3H_y5S7B8bxbUC60 v6ig.xKputeWnrmt.F48O5OqAUVJPYYNNtjol4Y8Wurb7Og7qR9VZ6x_ruCxEsSPSapH8UMJZqtg .92pMzovfkh1vNgg- X-Sonic-MF: X-Sonic-ID: 8f1fa497-a976-4b40-9648-59334886d986 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Nov 2025 22:09:36 +0000 Received: by hermes--production-gq1-86c5846576-hh7b7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7466aa4538cac4c1533a69c4f7bbe05e; Tue, 11 Nov 2025 22:09:34 +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.700.81\)) Subject: main [so: 16] armv7 chroot and lib32 use: example fio command works on real armv7 system boots but fails on aarch64 chroot or lib32 use Message-Id: Date: Tue, 11 Nov 2025 14:09:23 -0800 Cc: Robert Clausecker To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; 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]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from] X-Rspamd-Queue-Id: 4d5ggW0HYtz3Fbn Due to my normal environments being main [so: 16] based the examples are various vintages of 16 based. The main's are from official pkgbase distributions, not personal builds. I do use the non-debug kernel variant. On a real armv7 system, booted from a armv7 kernel, so far the example fio command has worked correctly. But moving that same USB3 capable media to an aarch64 system and mounting and chrooting into it to do the test in the armv7 chroot fails. Both the RPi5 tested and the Windows Dev Kit 20023 tested show the issue. A lib32 example on aarch64: # /usr/obj/DESTDIRs/main-armv7-chroot-ports-main/usr/local/bin/fio = --name=3Drandom_rw_test --filename=3D./testfile1 --rw=3Drandrw --bs=3D128k= \ > --ioengine=3Dposixaio --iodepth=3D256 --numjobs=3D4 --runtime=3D120 = --time_based \ > --group_reporting --direct=3D1 --size=3D1G random_rw_test: (g=3D0): rw=3Drandrw, bs=3D(R) 128KiB-128KiB, (W) = 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=3Dposixaio, iodepth=3D256 ... fio-3.40 Starting 4 processes fio: io_u error on file ./testfile1: File too large: write = offset=3D772538368, buflen=3D131072 . . . (lots of the above) fio: io_u error on file ./testfile1: Bad address: write offset=3D524288, = buflen=3D131072 . . . (more "File too large: write offset" notices) fio: pid=3D2078, err=3D27/file:io_u.c:1982, func=3Dio_u error, = error=3DFile too large . . . (more "File too large: write offset" notices) fio: pid=3D2077, err=3D27/file:io_u.c:1982, func=3Dio_u error, = error=3DFile too large . . . (more "File too large: write offset" notices) fio: pid=3D2079, err=3D27/file:io_u.c:1982, func=3Dio_u error, = error=3DFile too large random_rw_test: (groupid=3D0, jobs=3D4): err=3D27 (file:io_u.c:1982, = func=3Dio_u error, error=3DFile too large): pid=3D2077: Tue Nov 11 = 13:31:32 2025 lat (usec) : 500=3D1.17%, 750=3D0.68%, 1000=3D1.66% lat (msec) : 2=3D3.71%, 4=3D5.27%, 20=3D3.22%, 50=3D32.81%, = 2000=3D0.59% cpu : usr=3D0.19%, sys=3D0.64%, ctx=3D85, majf=3D3, minf=3D56 IO depths : 1=3D0.4%, 2=3D0.8%, 4=3D1.6%, 8=3D3.1%, 16=3D6.2%, = 32=3D12.5%, >=3D64=3D75.4% submit : 0=3D0.0%, 4=3D100.0%, 8=3D0.0%, 16=3D0.0%, 32=3D0.0%, = 64=3D0.0%, >=3D64=3D0.0% complete : 0=3D0.1%, 4=3D99.3%, 8=3D0.1%, 16=3D0.1%, 32=3D0.0%, = 64=3D0.0%, >=3D64=3D0.4% issued rwts: total=3D503,521,0,0 short=3D0,0,0,0 dropped=3D0,0,0,0 latency : target=3D0, window=3D0, percentile=3D100.00%, depth=3D256 Run status group 0 (all jobs): Being in a armv7 chroot and testing such (with a simple fio command instead of such a path) looks the same. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Nov 11 22:09:50 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 4d5gh25451z6H6Jw for ; Tue, 11 Nov 2025 22:10:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 4d5gh21yzrz3G8m for ; Tue, 11 Nov 2025 22:10:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b6d402422c2so42432966b.2 for ; Tue, 11 Nov 2025 14:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762899004; x=1763503804; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yDs2EPKFsjcusDaqR7IOaPGNFqCcmp3kZLCxsuh25sk=; b=Oly8TQOJLp08bbCPSKgDlV1w58SZduZjAZ56AYn5oyB2zZOskTAITrjnXFgotShHD6 FbGYwzkHhga/CD1iqBgh4jkold/2+MevV8dvxfgNTbkSMpjuNJFCxrlCAOB7gL4PzbUI TUUkMk9fA/m4g+UA5DyjldvdzpaKjjpImMOVqoa6OhVyMa03wW5zF63cC/Tb2Okk4qa4 zFVCUqDeoVhRGPVJUzHYq9GB02RG8sRgnf4jBn9xDUExvY9VYXFMvrSXeeij7NKh75k6 TvWJa/+iXTOiII4TFFEBv9BnrKQCo5MOFLtt9SFuecXlTgUinMM8W0sMev6EM2uO7J/u rSoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762899004; x=1763503804; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=yDs2EPKFsjcusDaqR7IOaPGNFqCcmp3kZLCxsuh25sk=; b=rigLUjzoMQvb+r084zNYYqh5VSaaMLE5Yvu9wsdvUI5QZs5IEJsoRtBJNRTmwawUGV tqS46N3h4RLMyyeh/k1iPyNoJa9XD+DGMeUv+Y8kxqqTFDkjOd52p4pJnqf6EbsfVqd4 roi+PlWBLmd9d3xygAdf+F/u1zH7UtFyF4zy6yB1xV365qwVXOkMm4rMOxAcpxumRu3F tC2d0sJOW7Pm1wmkPBiH8QEulG1ZFS27Ipe5RPNUMgQ2sa1UbXhb5GUN2xSq0NPXLRJl VM1J1Z4AXGNrpcdI9Tvt93QudvCIUdD2UGr/CHqPkmMrShfqBAjs60sNXh00a66FPEtB FZMg== X-Forwarded-Encrypted: i=1; AJvYcCVUyVTWiCgiyU0mdDNUN6wnjf3oL7F0WZhRUzUqKV3RshiyhmP0117a+T3Q71dBBsV0fYGsqDmibGUAfngml7c=@freebsd.org X-Gm-Message-State: AOJu0YyEU9lMbzyChclF5zEe/njnMMK1ej3KffKiaDHnbPUiqbucCXU/ DlBZLnvjDTN8sjF6XzAUBkgTad7jEn/eZHEGQL8IdNT52oc6H2A/bkR/4N7tFb4lcf3sKqNaf0e /SPTYy0C8z0WkFBgslUkFXmXsxkhK3m9kifo= X-Gm-Gg: ASbGncsX3vqZmilC+ZJDILehb7aO+IcRF3OBUt2If9/F4EBOYTBfUZQVLR+YYLpj3qL eNYGG7ir1o/VqROpDVDTRdPh7ugjTlbF1g1v4O83f27djnJ+egYt6LEiejypKl/7ruEmcyOB05k ++luUZgjS1/zX6mKYvrhZViqdXWtuppGNnaoFchsrAkDltjVQFRwyLBxPjld9w3J1KAgry1rIO/ lLK/bjt8Lk4ZStzl310v4FLkfhiwhuCvces8ng51Uf9exJB0a02lURnUOAbaIFr5+u+Qw== X-Google-Smtp-Source: AGHT+IGXP5SG7OeW4aX4V6p7Xlt1CwnW/GDDzsJMS+o5+WH4owYuZ9L0D/YeoCKcmFGRYpx9nvCurb9wc3xt+HRA4iU= X-Received: by 2002:a17:907:2d2c:b0:b70:b71a:a5ae with SMTP id a640c23a62f3a-b7331aa3be1mr77126966b.44.1762899003793; Tue, 11 Nov 2025 14:10:03 -0800 (PST) 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: <2100145914.14642.1762672441817@localhost> In-Reply-To: From: Rick Macklem Date: Tue, 11 Nov 2025 14:09:50 -0800 X-Gm-Features: AWmQ_bkKEZ_4YjOzBUpC_CJlTx5kQs2GRxxgs14OqrzEqoDrRSbb_N_yO3K0NFU Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: "Peter 'PMc' Much" Cc: Bakul Shah , Ronald Klop , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d5gh21yzrz3G8m On Tue, Nov 11, 2025 at 6:54=E2=80=AFAM Peter 'PMc' Much wrote: > > On Mon, Nov 10, 2025 at 12:58:17AM -0800, Bakul Shah wrote: > ! On Nov 9, 2025, at 12:52=E2=80=AFAM, Rick Macklem wrote: > ! > > ! > On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop wrote: > ! >> > ! >> Why is this locking needed? > ! >> AFAIK Unix has advisory locking, so if you read a file somebody else= is writing the result is your own problem. It is up to the applications to= adhere to the locking. > ! >> Is this a lock different than file locking from user space? > ! > Yes. A rangelock is used for a byte range during a read(2) or > ! > write(2) to ensure that they are serialized. This is a POSIX > ! > requirement. (See this post by kib@ in the original email > ! > discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-Octobe= r/004704.html) > ! > > ! > Since there is no POSIX standard for copy_file_range(), it could > ! > be argued that range locking isn't required for copy_file_range(), > ! > but that makes it inconsistent with read(2)/write(2) behaviour. > ! > (I, personally, am more comfortable with a return after N sec > ! > than removing the range locking, but that's just my opinion.) > ! > ! Traditionally reads/writes on Unix were atomic but that is not the > ! case for NFS, right? That is, while I am reading a file over NFS > ! someone else can modify it from another host (if they have write > ! permission). That is, AFAIK, the POSIX atomicity requirement for > ! ead / write is broken by NFS except for another reader/writer on > ! the same host. > ! > ! Another issue is that a kernel lock that is held for a very very > ! long time is asking for trouble. Ideally one spends as little time > ! as possible in the supervisor state and any optimization hacks > ! that push logic into the kernel should strive to not hold locks > ! for very long so that things don't grind to a complete halt. > ! > ! That is, copy_file_range() use in cat(1) seems excessive. The only > ! reason for its use seems to be for improving performance. > > Not really. ZFS can do what might be best described as > "block-level hardlinks": if you copy an entire block, it is not copied > at all, and, also quite interesting, it doesn't need diskspace. > It is just listed as duplicate. > > So, how big is a ZFS block? That depends - the default was 128k, but > now often desired is 1M, and people are already talking about 16M (not > sure if that makes any sense, but probably they will come for 256M > sooner or later :/ ). > > I could imagine some kind of max-copy-file-rangelock setting with a > default of 16M, and tunable for better or worse if really needed. > But that is an operator's viewpoint, I do not know if this is > feasible from design/implementation. > > ! Why not > ! break it up in smaller chunks? That way you still get the benefit > ! of reducing syscall overhead (which pales in comparision to any > ! network reads in any case) + the same skipping over holes. Small > ! reads/wries is what we did before this syscall raised its head! > > Out of curiosity I tried to look at practical size parameters for > read()/write() syscalls - and that runs with 1GB blocksize, if you > really want it. So if you do > $ dd if=3D/dev/random of=3D./XX bs=3D1073741824 > $ cat ./XX > the cat will wait until the first block is completely > written, and then deliver exactly 1GB. Yes. A large read(2) will exhibit the same property (rangelocked so other reads are blocked). It's just that read(2) doesn't normally use really large blocks (as others noted, 16Mbytes is probably the largest useful size now or in the near future) whereas using a large size for copy_file_range(2) is useful. I suppose you could argue for using 16Mbytes instead of SSIZE_MAX, but I think that will still end up with increased overheads for ZFS, since it will require many syscalls instead of one. I am not at home, but when I get home in a couple of seeks I'll see how long it takes to copy a large file on ZFS with block cloning enabled on my very slow hardware with no separate ZIL device. rick > > > cheers, > PMc From nobody Tue Nov 11 22:16: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 4d5gq058Tjz6H6nc for ; Tue, 11 Nov 2025 22:16:12 +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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d5gq04SXyz3JcP; Tue, 11 Nov 2025 22:16:12 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762899372; 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=oyPvP+k0vRYPIhq9j5Cw8sUvshBKLSR2BSfusDchUqE=; b=d2MwJmedn34m9qf12zkjf8Axwxoxx3efwUh31zX9JEiyoNCGNEOLMtBP3nnaAUyGlBrNIA bYe8fjnDtOooGgbP00yVHaczdUbWME/zd/h3WtFCr4nmUEixmG8yxyyxE7hp2twlnZf5/h p5ngdIHpyagsMQ7WJk5tl8Bg7VMxzmxoZvE1oHzlQRiCGqvGWd+35boJEDRkXO871VlHVN UeMCAvBezzPVgRwAYhlbpJyJHv0d/Irz24FIX32Cji3CBHt4Jj5CfoFpsO3HImD3zAR6Ev 4Y2vYT8MD1mRzECo1QIGyW/Gu9333BDqUbApnFFnw1iUjaU4hEhSxCqjPjjBwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762899372; 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=oyPvP+k0vRYPIhq9j5Cw8sUvshBKLSR2BSfusDchUqE=; b=EjQ76EjNN5kBuz78hZDsOgu2sPjlsbknIXgoMk/kAnnVXKbKs3GHN+FuK28jNJJnhLwlqo HyjjEp5v5ah6L3KcV3s8eXv/TxP02ybFr1PiC47G3b8FGfpzteaQRcKIQ4F6I07r6dAt+X PM/shsrtmBZWVRGodfXXYOHdwooxmGRJGyctci6Z5CCGONYeWFzra1sqJEP8+14GHFCv9j h7KKPIkbITtB9B5i9RVHCaKkR7CGTECV18+VBl2rz0HI0A8DqWz0RFwKkbx247djuyHRi9 UzG8ybiYFTErYi5GRV1S8uOuJ1IfdNkBAVFcX55/RyKMIQGDUGULdb8BxGoSPw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762899372; a=rsa-sha256; cv=none; b=i0I9Fbs6XilyaFK8jWhlhEIDXFwuIsBEv/H4j7Z3z8E/VaQBCysBPC1G5FGPl4sRu2nsi6 z8d3z0cf3Srm8vYGQJcO54WSEN/OAo76KBOG2AgUmHuqWrov0uIH59tzeP9IgfOT70lJ2N Qp8U+qXyZasMWDr90xoiKnEpTfRoLnmYTA1gM6eSFsStYsjRyC9d3G1XWJEjZhebP2Li7E pzGOnQ9daKZmsJoUSc3EZ2dsW33At6xTowmI2ApVs88FZ64mpUAdvl7JmzokQTjyf1eSeR iSqT9nIlvlUbOQOOGz2gjpMYnQ/eaaZDwIJsT4LrkjCuDuagITtYSrYMB8Ju8g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 "E8" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d5gq02qQ1z40T; Tue, 11 Nov 2025 22:16:12 +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 749FDA64806; Tue, 11 Nov 2025 22:15:58 +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 7146F2D029E7; Tue, 11 Nov 2025 22:16:10 +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 QatPlK00ecAI; Tue, 11 Nov 2025 22:16:09 +0000 (UTC) Received: from nv.t4-02.sbone.de (nv.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:22]) (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 670CB2D029D8; Tue, 11 Nov 2025 22:16:09 +0000 (UTC) Date: Tue, 11 Nov 2025 22:16:09 +0000 (UTC) From: "Bjoern A. Zeeb" To: Steve Kargl cc: Ed Maste , FreeBSD Current Subject: Re: Backout git revision 4179e6b78297369f [that is also stable/15 and releng/15.0 as 62c3b77d1d10] In-Reply-To: <5c38b898-3b3a-43c5-9e91-5e313f978b2e@comcast.net> Message-ID: <42p211op-8981-3n26-p64o-r779pr8p814@serrofq.bet> References: <288036F0-180F-4DF4-94FD-66365B7504EA.ref@yahoo.com> <288036F0-180F-4DF4-94FD-66365B7504EA@yahoo.com> <255c624f-765c-4091-b3a5-22d439d292a1@comcast.net> <5c38b898-3b3a-43c5-9e91-5e313f978b2e@comcast.net> 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 Tue, 11 Nov 2025, Steve Kargl wrote: > On 11/11/25 12:12, Ed Maste wrote: >> On Sun, 9 Nov 2025 at 02:01, Steve Kargl wrote: >>> >>> It's not a big ask. Either back out the commit or maybe, >>> just maybe, someone can commit the patch in PR290432. >> >> For current, reverting the commit is a nonstarter. >> >> In PR290432 I don't see a report that WANT_NATIVE_PCI_GET_SLOT fully >> fixes the issue, just that it fixes the build. Can you confirm that's >> sufficient to fix it? > > Yes, it fixes the issue. After the build completes, one > can install drm-515 on freebsd-current, and life returns > to normal. > > IIUC, bz@ indicated that the patch may be break stable-14. > I don't use stable branches so cannot verify. May need to > use a _FreeBSD_version check, but I have no idea how that > would look. I have a todo item now to install myself a pourdriere for all currently supported branches so I can test and if it does not fail push the fix into ports. May take a day or two as I have other things on the plate as well. Your fix wouldn't break stable/14 but if I'll merge wireless that would, which is one of the reasons stable/14 hasn't seen a lot of the wireless updates and I think then the solution will be to have a backout patch for 14.3-R and stable/14 up to that point. Or I'll find I cannot MFC wireless as it'll just break things and then 14.x is stuck with whatever it has now for the rest of the branch lifetime (which is still quite long). We'll see. /bz -- Bjoern A. Zeeb r15:7 From nobody Wed Nov 12 16:14:50 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 4d67ld6CXGz6GCgk for ; Wed, 12 Nov 2025 16:14:53 +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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d67ld5bTTz3JkY for ; Wed, 12 Nov 2025 16:14:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762964093; 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=i7oQUdIaV6UXcRbbL5v0TI9GigDKAp93dTZT3sA/Vc0=; b=DqIfwiA07uYxLk6QyhhgY6vGqT57aGq2Se+1tiA5GiW4yY+Z0ErZMpk6JBF2ekaQYGNVGx 7YAvts8X8XXTlcihRdQ4fESDdjiS2cz2f4v4rMHBpDbrWkVPteAEdm4NsO38DWfDPkmcuZ cxMivInJDhDcB8zxzeRiAfk+OEAu2k8DvZHgSjhd14oRKWS3aVsx4w7Sr5fCKrHQ2c9f3/ I2pKkr/Si2Mx0nfnwkdYcx2R967I8r9x9Q8kQevUcti7pBklaS6ZwYowxWVzv4ORyN+p6t 8P8l0Z4h6UbdMWOfFVS8UJhtmTFI3wyur7hZ8cvDv4+zBqAgHOXH5ZRILVXFUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762964093; 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=i7oQUdIaV6UXcRbbL5v0TI9GigDKAp93dTZT3sA/Vc0=; b=wCEaKs7lsmS8Fjcu9ixj+Iawhg+ULZwMmsKltITL0ki10UyuPacpJztavhTOaWQfqZyLmq xHQzDuM6tKVERlLqk3HysDe/CwWfaI+J8Br+p3ma/Aa7STPCK4YaC69HQXQloZv/BWx6te nIfHLzq3cQwcd+yXzoMrgo3jdNKbxJNaIWZcq66d60UTFQvuPoQo1JXeIqfUg8Sx5s7N+W o3sQKWqfIJBHVQU+Xn1cmG5a8zy9xmy8yJ3D7U2tGQdgyh5vmVDozVsAVvHagohV29x5Y7 cUJdEr1TYS0OIOXQ4boohkvhzSnHr+TCVSZRFPMd05M4Ekf0b2osS2JiJX1J7g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762964093; a=rsa-sha256; cv=none; b=jcTJrx+f9biWKtwLnkwttHOjVQjKTkZkf757z8cUZ7FFFq7LQKPhyzLdiEhsX9fKAjgR1d Jc1tZos0eOW2Hh4y6lKWHFvAWhfK2ftZ5T9jpVxIS3nBnjmGfBcRgCdsozl+A66AmNT2vk 6EG7qgR3cw7P6sSqQ9EQEHSvsJXVanYEM+i6wQJmiXlH298LCuIQGZgjqo0OPlKCdMFQwF PsO43cRwIlK6u5RIo+nAt3bXZBsJP7llX6Ll22Xlk88V3j1FnvSEe6WHwYt0ww2LfsQNkd 4z0LH86fbAVBy6bIuZG/QuVU3iM6/tJCmMNIkpIQzhXiZ0kWKRpFeM1yLFygWw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4d67ld3Gxwzkh2 for ; Wed, 12 Nov 2025 16:14:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Wed, 12 Nov 2025 18:14:50 +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 Content-Language: en-US To: FreeBSD Current From: Andriy Gapon Subject: keyboard in wrong mode after VT switch from X 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 usually work in desktop (X11) environment all the time, but recently I had to troubleshoot a problem with Xorg configuration and had to switch between X and a text console quite a bit. And quite frequently (but not always) the keyboard seemed to be in wrong mode after a switch. At least, that's how it appeared: most key presses wouldn't get through, but some (I think Enter) would have an effect. Switching to another text console and back always fixed the input. Not a big issue. Just sharing. -- Andriy Gapon From nobody Wed Nov 12 19:38:08 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 4d6DGP3q14z6GVRR for ; Wed, 12 Nov 2025 19:38:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 4d6DGP1wH2z3vs9 for ; Wed, 12 Nov 2025 19:38:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f50.google.com with SMTP id ca18e2360f4ac-94863b3620cso5155139f.3 for ; Wed, 12 Nov 2025 11:38:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762976300; x=1763581100; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=e+JZctcSw68BBveDeO9Rk4nx839n5m5AqEuS8nKNgJQ=; b=nTneFDwve5NGaBomSmBq9tBz5pYEpFi+ge8S6Zs0dvh7TyoeYPL0vvIlKip2FWg1GK KvHGH1ljpFd0gPE/ATzriVjAdlqMy+uKLmhsl65Q8A5i731kOB/3N89upwB7HG+bHb8j Uc0dBS59Yyx90tZeyhUfJ69+8uLcXhbUf4gTBJ2GqRMAuVWwzQAI2Fu2aHs6ZgfMjdE9 6zt/kFNSTrAtmkPetF6+1t+zvq06ww6sfW2M+hx/+uSoRvjmGjBemLkrkIjlqW02+dib gWcn8hE5ODycIcxaEsvctgxHKEmUhksSEJ9J9MUa//i44k3gGcJexRJq/ARdj0JlI4xa cVbg== X-Gm-Message-State: AOJu0Yyrsf7CvftWyG/YaEqohye4zrdxZAgWFbeNegGVjwE1LcZGspne HdJ2A4UP8QaALhrYe2STdNBSJwDxhZViYWycGEPiA47N5lMjqVfqEDlipG68OnjOjXYskTonMxc 6BXN/WVonwesd0mSqUc/JmZ5L1QZG4x+3rQ== X-Gm-Gg: ASbGncu761dcdsqkwjI9O9FWM0MdRjQHZ768ZvgN9zR6gd9WDzTtL/S5ice8J6mXOZ8 UaykQ2my+ZfEw1J6exrzRgJgLeCrBc1HfvUBT9S6Fj2w2aiuF9qFtIXBUc0usi4RB+asX8fBDDv ra29OU9ralVXXO3IZn7udbYTN9n49I0T/bGPLRZc/4yId5gPSHjPjDQXd69LvzePRn20uGxNfoL OFu4u3LI212IT1UjX5gPVLa85u78qwSNO9239PcVew2uwWh1JaQptyGy5vbf3MZgdpOBqHxI4az rTSKvoSD/uvGHp92 X-Google-Smtp-Source: AGHT+IG9WDsZXgVWTdgNcEQol6r3ibgxTpB9f83vZO3TNJvWBGb/NlNqDEX5HTcv/NsCq40YpXq26G+urVGn3zHRf/I= X-Received: by 2002:a05:6602:1550:b0:941:3f8:5bbc with SMTP id ca18e2360f4ac-948c463c62bmr537790139f.11.1762976300139; Wed, 12 Nov 2025 11:38:20 -0800 (PST) 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: In-Reply-To: From: Ed Maste Date: Wed, 12 Nov 2025 14:38:08 -0500 X-Gm-Features: AWmQ_bnaXz5f53eXz2v1TMYp8cfbRJDvpeUZCHOo_rdnPB8VDJojzVjKFZzhm9A Message-ID: Subject: Re: keyboard in wrong mode after VT switch from X To: Andriy Gapon Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d6DGP1wH2z3vs9 On Wed, 12 Nov 2025 at 11:15, Andriy Gapon wrote: > > I usually work in desktop (X11) environment all the time, but recently I had to > troubleshoot a problem with Xorg configuration and had to switch between X and a > text console quite a bit. And quite frequently (but not always) the keyboard > seemed to be in wrong mode after a switch. At least, that's how it appeared: > most key presses wouldn't get through, but some (I think Enter) would have an > effect. Switching to another text console and back always fixed the input. I think I've seen this sort of thing being caused by incorrect modifier key state - that is, it's acting as if ctrl and/or alt are being pressed. If you get in this state again try pressing and releasing modifier keys to see if that clears it up. If so, it's a bit of an unfortunate workaround but at least will provide a hint for next debugging steps. From nobody Wed Nov 12 21:20:40 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 4d6GXW3cPQz6GcqJ for ; Wed, 12 Nov 2025 21:20:43 +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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d6GXW2yv5z46wd; Wed, 12 Nov 2025 21:20:43 +0000 (UTC) (envelope-from avg@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762982443; 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=RaTq3J0j0fDeZ7ZUePAKyRHuQDpXBUObne/N4dmyaYE=; b=XEdKEa3sIgQN+7M3RuN2yFEGaf759ZG5yIHRyWF1cOoq85CKXHl+dVuU9GmsgI9SWi3MJJ SCzLgRcJ1TcMDF22aI9cvt6TdD9PpSgj56SLJggRbjlSFN/LVaDRLwlTwF5sH2TNIm10tE HNJFtBeKYK5pcNaJBb+NPvMOp6l638D8VA1EFT/bIMxSnXITMeHtySV6GUtB3itQ+txj9N RbbAtW7/G9kD5GYjZu/9kPE3iY8E7QqaCtgBguxMK1uoV8LCTpcitsN3eQzfbDr9kmqlZy lyw208YLnWQXKVYk7a4+mBkFo8kwrAQXDDSmwngVQDfU36+YXMAySPWjnY1/BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762982443; 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=RaTq3J0j0fDeZ7ZUePAKyRHuQDpXBUObne/N4dmyaYE=; b=ubEk1RvWWzJKiYF4/dfNkF3LOrLk/q3UPTmbdw5SQ9wMwNdcENh5GjQHZ/nIpFitBeTywT ZQAE929VuEdMzdiM5ISr0YPJYYHXvfU2CN04rhbi64iM4c3+QTGgpDiUVV8oDj4mvpZeO8 WtvGEM9ycISbDeq2rD20+yi0BA32A8CdHFvvLZkrW0ZlDDf+tX6giF02nnUFWeF/KJVFI3 BPOmfgBNebJNe0xnPFMB/b0dhhldMdjB9T1jqY6+bJxFxU0U4Ft10BELdwvePb009gIW25 +OqnKM1ih9/Ug2sYkqgv7K+TtPCr46xEZtWuS4k8te1PqICFc2hoIxBRagkX4g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762982443; a=rsa-sha256; cv=none; b=QEbADfngy6+CodMXPuhCGEYQX3OekdURvUR/ECuDgdRoueIOOIOMej4e02POTPGYfgajgZ bZs9PylE59tBHKSfWNeQHBWdSE63A1LCT70DjbzVPhYrRsajuBpwFUPf/72YUTpTQOX22R 3eSAbZQwsumOhezwx0+pjz9/c5A2hWCU5flVQRfFeMQl9BOTYpXzcHOybKjZd7q3hsVdY3 9bhEQwRVQj4Th/yzKSizdKZxPtNHP41hVBMTmw8FXDmDSj9sNzlEA/hIzNk8dxvEICvRI/ 32q0FtfwmnRbaCOPocFJTHFNd/TFohq56dKG6heG+C3KkZLjuAnS0y/QWXrueQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4d6GXV6qsDzrHC; Wed, 12 Nov 2025 21:20:42 +0000 (UTC) (envelope-from avg@freebsd.org) Message-ID: Date: Wed, 12 Nov 2025 23:20:40 +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 From: Andriy Gapon Subject: Re: keyboard in wrong mode after VT switch from X To: Ed Maste Cc: FreeBSD Current References: 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 12/11/2025 21:38, Ed Maste wrote: > On Wed, 12 Nov 2025 at 11:15, Andriy Gapon wrote: >> >> I usually work in desktop (X11) environment all the time, but recently I had to >> troubleshoot a problem with Xorg configuration and had to switch between X and a >> text console quite a bit. And quite frequently (but not always) the keyboard >> seemed to be in wrong mode after a switch. At least, that's how it appeared: >> most key presses wouldn't get through, but some (I think Enter) would have an >> effect. Switching to another text console and back always fixed the input. > > I think I've seen this sort of thing being caused by incorrect > modifier key state - that is, it's acting as if ctrl and/or alt are > being pressed. If you get in this state again try pressing and > releasing modifier keys to see if that clears it up. If so, it's a bit > of an unfortunate workaround but at least will provide a hint for next > debugging steps. Yes, that was it. I've just repro-ed the issue and pressing Alt helped to restore the input. Thanks! -- Andriy Gapon From nobody Wed Nov 12 22:25:02 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 4d6HxV6kpjz6GhXs; Wed, 12 Nov 2025 22:23:58 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d6HxT4L22z4HZJ; Wed, 12 Nov 2025 22:23:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5ACMP3sO029968 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 12 Nov 2025 14:25:03 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5ACMP329029967; Wed, 12 Nov 2025 14:25:03 -0800 (PST) (envelope-from fbsd) Date: Wed, 12 Nov 2025 14:25:02 -0800 From: bob prohaska To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld 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-Spamd-Bar: ++ X-Spamd-Result: default: False [2.93 / 15.00]; AUTH_NA(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.99)[0.993]; NEURAL_HAM_SHORT(-0.96)[-0.958]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; DMARC_NA(0.00)[zefox.net]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4d6HxT4L22z4HZJ For lack of any better ideas I've collected some of the assertion failure /tmp files by host at http://www.zefox.net/~fbsd/assertion_failure/ Thanks for reading, bob prohaska From nobody Thu Nov 13 08:11:51 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 4d6Y0Q3v6lz6GS90; Thu, 13 Nov 2025 08:12:22 +0000 (UTC) (envelope-from ronald@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d6Y0Q05PPz3BwM; Thu, 13 Nov 2025 08:12:22 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763021542; 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; bh=1ADMUxl5y54Bf3Owgx9KtUxzeLKpwXkmodSDFORvoFg=; b=H2CdS3ykQ49C0ADnW65lR+cDu1oz9g6VXPFlIR5d+YRMettynTNoevObKMx2FFdErkN0Tt 3Z3yCokWho0ayLlV5vvmBvwkuV09HWh2RllP9Z0DriNXdU3XBO/2Gx4ihep+rjFgDmF2Rf PDWBQ/+VdMoVA+3lkS5JAAs1aSNIn1lE/I7haee94K/wi2koB8Vy8uUIeb/8CPkkcdhFlb fDGZyxEueqsUmhvQWFmIT3eGzN+CmyzJg8lBs6ecLMBMYHLJ5XUwim9NNUrfT2/aLwfqdy YJtppu7TwWwI0OZmoMo2FSHi7S/qt/tTqKbzADnqyCG2wz8Bm/Uy/TkOZv5b+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763021542; 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; bh=1ADMUxl5y54Bf3Owgx9KtUxzeLKpwXkmodSDFORvoFg=; b=R+6EiSDOzmvoHGcliDoP1r62UjV3i1gL6OP22bK7osdRRTqk1pJlKwU8E/039+LlytDjR9 R36eSYgPvI8Cd0ObeySu4EXZ0+2niJZ1VSRD2Q6MLdElMBHodAJEHw5FjuqCuUMPRakL3v /6IoSiBYCsj0kWgPf5hcmetbmO3GiXiD5iwE1j6eM38Bu8TEx7efTZiTZqsw3Ji2uKcjDX vckq/G1ZB45nifG65RjjbHx2oOYJLsLR1HmGbWZMfynjwNbvup6S9faoy56DjryAWLtyk8 Em936Yy5TaECZsKuvZ13WnXcORBnJzEbYRUh9cFK8VJD9hLjFwV4LSLk1KTr3A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763021542; a=rsa-sha256; cv=none; b=YHppkyHFhzgWiyfCMAiPT/t7QXh7JJaeKbxHHvjwLWAu7If+iOsX2NBV/ViUI6s7/fXOGl hNGvdlXiVKm5BdwQ/NXiTFfRbuDA4Gq6QRjWsXiN9HF/QRYGr/rTs/hDAuHHcgxmOy64gT /aSodd55fNrBhiTmktATkAKUQIDraw7FHinGdLgbjgae37oubUlkkzVvrBIX1cJAdo1Ufx hE9QAe7dFv+caq3DFtL9Tby4FmWzsbqOpjJeN8jypD0CDLViYpmSRbaxFDJP7F3dJyip3/ KcxCXaovnG18L9tRyWUpUym8uaGoRFp/Qo5PWie6mrrZly9cslJgrzfe94i/ag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2001:1c00:270f:14b0:fd1b:708f:f8d8:f242] (2001-1c00-270f-14b0-fd1b-708f-f8d8-f242.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:270f:14b0:fd1b:708f:f8d8:f242]) (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: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d6Y0P39LNz154m; Thu, 13 Nov 2025 08:12:21 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> Date: Thu, 13 Nov 2025 09:11:51 +0100 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 Beta Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld To: bob prohaska , freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: Content-Language: en-US From: Ronald Klop In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Op 12-11-2025 om 23:25 schreef bob prohaska: > For lack of any better ideas I've collected some of the assertion failure > /tmp files by host at > http://www.zefox.net/~fbsd/assertion_failure/ > > Thanks for reading, > > bob prohaska > > A really uneducated guess, but might the update of jemalloc [1] have introduced some subtle issues on armv7? You can try reverting: https://cgit.freebsd.org/src/commit/?id=c43cad87172039ccf38172129c79755ea79e6102. My thought was triggered by this as a build of opendjk11 failed with a jemalloc error. https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025-September/804963.html Regards, Ronald. [1] https://cgit.freebsd.org/src/log/?qt=grep&q=jemalloc From nobody Thu Nov 13 08:17: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 4d6Y760Nrkz6GSf9 for ; Thu, 13 Nov 2025 08:18:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 4d6Y755PTRz3Drl for ; Thu, 13 Nov 2025 08:18:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-3438231df5fso577867a91.2 for ; Thu, 13 Nov 2025 00:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1763021883; x=1763626683; 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=SvtQH+ieTruuulcMRgpVQbp2rA1tk0t66JfqTNlZc2w=; b=SSMXGnZNevU5p+W+b4k4/Dw254K8c5nIIuU0/2HD9CEytmscK5KUgDv3sFw1p9d1Ws xOJLHx1qKR/hQEBlQxk21S/kwe4GJPyR7Spep+TrpHT/+lnhRwlhOAErzthZ4GYYJFpZ yqN+XGh3bTilgBqMsuRDWZxEa0/ZvuOXeQrhkR//xM/VgZyz+r/1Mh/83nqzon7o94XE RqucVLSbKj8DUEoedreCeyBKt6BY+iNwdR7bGnGw0zhxPX7dmwVVPh03THD7ItjCuYFe WO8YNtPSte9i32mVMXbpCGCqz/t55xrpbqXNrgCXCjMqlU0oqIHS09pY+fftT5UM1Ydl iswg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763021883; x=1763626683; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SvtQH+ieTruuulcMRgpVQbp2rA1tk0t66JfqTNlZc2w=; b=t8b/doNfJKwleAJnEyjPjbTxV3gCYgAcEKUyXWzKsb5syvDLaTcEiBRzsqaCFPFo+s JJ7Gsp9BrmUKPm/u4rJ2AdxFOz2oYSo1N2Ey3yo5qr37rujuYG1FAUMhtLrJr6ZAwpOb VsQfei7LNpHPIGkNFeRlKTNyLUUm6PeYi2Rzn76kk0+C4Y4wbg77+U8zXWVdgV43D/Vv Q5V4vduEcwjZO5jcAyj3uARaOgqBHOwRMyCnD6MOokwXiVi4A/E4Bft4zHeoy3G95jnf pqR7oU1BmJSZMFQs1XQskunuXX3EWgd8v989/pBoMsoTUfs4gmfIWfFq3jo32csYBC5J 0sPg== X-Forwarded-Encrypted: i=1; AJvYcCWF7uwI1d8pr9q9VEYVmacgTrkD2P7TI4bHiqJcRR8ULJLcm4t0EhORAEv+TDx4I41m3Qw4aubBnjJXMx6wqzo=@freebsd.org X-Gm-Message-State: AOJu0YyM7Fa4Ktizmo9mZ4g/ww9jepWQZM+AyOD60c+c11jU1l+8eMIn ERbSfNuv6wsM/mO4Asjx9qRVoJDRWN5MXufCn7mzo9OzyrG6yh9SjRCoZL1qKHcBZzlqRsnXpPp 4rmgOjkwyQnlz4XE2jyDaqoD3jDGnvzqWeqDiI9jeww== X-Gm-Gg: ASbGncsZRrAmmH8B1T4FLIJB27mXJtTIi6JxLjAYHSV2A9y83bz1Q9giKCCVXoMF1/O KraGKVODYdLO43XiHb3CbMI1Y1bLEJbJwe+gnpoEicvtXV7tTKJjTUtxU3wT+bYIAWyFYhtwgKk L1hQ9GlA9Sgh3yQW7138h/tKm3vmgX6QqagJAGnzoNIcOrd8DTbbDChWy9JRF4TVKXzzxdpoqNg CFxxnj+QQYZj5B0Lw+/yk8jnmhIVzSdGM/k1Vb785LlvOnDAtCDUetVyELG X-Google-Smtp-Source: AGHT+IF7WxD1/hP6ZnPrAlvqf+RsC+wGz43eWsfWcCKNbZfl56gPCsOrkxWap/WVfqEKjWvLnasxN0hzHH1wRG2VS6I= X-Received: by 2002:a17:90b:4f88:b0:336:9dcf:ed14 with SMTP id 98e67ed59e1d1-343ddeadc5emr7475738a91.23.1763021883359; Thu, 13 Nov 2025 00:18:03 -0800 (PST) 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: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> In-Reply-To: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> From: Warner Losh Date: Thu, 13 Nov 2025 01:17:52 -0700 X-Gm-Features: AWmQ_bnfe-HFssR8Y7aOzF8cHJXBiXCoLFQVxnkJPiv0M5Ki2Gdiw_9uxoDI3g8 Message-ID: Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld To: Ronald Klop Cc: bob prohaska , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000016d5f106437585fa" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d6Y755PTRz3Drl --00000000000016d5f106437585fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 13, 2025 at 1:12=E2=80=AFAM Ronald Klop wr= ote: > Op 12-11-2025 om 23:25 schreef bob prohaska: > > For lack of any better ideas I've collected some of the assertion failu= re > > /tmp files by host at > > http://www.zefox.net/~fbsd/assertion_failure/ > > > > Thanks for reading, > > > > bob prohaska > > > > > > A really uneducated guess, but might the update of jemalloc [1] have > introduced some subtle issues on armv7? > You can try reverting: > https://cgit.freebsd.org/src/commit/?id=3Dc43cad87172039ccf38172129c79755= ea79e6102 > . > So, is this a new assert that detects a previously undetected corruption? Or is it a new error in jemalloc, correctly detected by the assert? Warner > My thought was triggered by this as a build of opendjk11 failed with a > jemalloc error. > > https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025-September/804= 963.html > > Regards, > Ronald. > > [1] https://cgit.freebsd.org/src/log/?qt=3Dgrep&q=3Djemalloc > > --00000000000016d5f106437585fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 13,= 2025 at 1:12=E2=80=AFAM Ronald Klop <ronald@freebsd.org> wrote:
Op 12-11-2025 om 23:25 schreef bob prohaska:
> For lack of any better ideas I've collected some of the assertion = failure
> /tmp files by host at
> http://www.zefox.net/~fbsd/assertion_failure/<= br> >
> Thanks for reading,
>
> bob prohaska
>
>

A really uneducated guess, but might the update of jemalloc [1] have introd= uced some subtle issues on armv7?
You can try reverting: https://cgit.freebsd.org/src/commit/?id=3Dc43cad87172039ccf38172129c= 79755ea79e6102.

So, is this a new a= ssert that detects a previously undetected corruption? Or is it a new error= in jemalloc, correctly detected by the assert?

Wa= rner
=C2=A0
https://lists.freeb= sd.org/archives/freebsd-pkg-fallout/2025-September/804963.html

Regards,
Ronald.

[1] https://cgit.freebsd.org/src/log/?qt= =3Dgrep&q=3Djemalloc

--00000000000016d5f106437585fa-- From nobody Thu Nov 13 09:07: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 4d6ZDM5dQ9z6GXCc; Thu, 13 Nov 2025 09:07:47 +0000 (UTC) (envelope-from cshapiro@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (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 4d6ZDL66lwz3PhC; Thu, 13 Nov 2025 09:07:46 +0000 (UTC) (envelope-from cshapiro@panix.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=aT2lrb9r; dmarc=pass (policy=none) header.from=panix.com; spf=pass (mx1.freebsd.org: domain of cshapiro@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=cshapiro@panix.com Received: from css-ThinkPad-T14s-Gen-2a (c-73-231-159-157.hsd1.ca.comcast.net [73.231.159.157]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4d6ZDL049Zz46TM; Thu, 13 Nov 2025 04:07:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1763024866; bh=l/c9MBifdDsOqnDr+SVsiL6A6AgAnW+88TrPy8e4RVs=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=aT2lrb9rSImhvec8nrCXbXnm7sxIL0uhMO5+2gxOQXprGUOc3Py+qrTqsBdw5Vc6p d5WDNHqnKkLLq8eJf9nT5KBgF7+nkQrRXAZ2Popu77siz6/GUl0PKMPvYMAkL5JLjR ozuBesgqARhnlIyFQeYfoZiz4W2UITGYaf8p+ZpU= From: Carl Shapiro To: Ronald Klop Cc: bob prohaska , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld In-Reply-To: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> (Ronald Klop's message of "Thu, 13 Nov 2025 09:11:51 +0100") References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> Date: Thu, 13 Nov 2025 01:07:41 -0800 Message-ID: <87ldkai9lu.fsf@panix.com> User-Agent: Gnus/5.13 (Gnus v5.13) 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 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.14 / 15.00]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_MEDIUM(-0.94)[-0.945]; DMARC_POLICY_ALLOW(-0.50)[panix.com,none]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; R_SPF_ALLOW(-0.20)[+ip4:166.84.1.64/26]; RCVD_IN_DNSWL_LOW(-0.10)[166.84.1.89:from]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[166.84.1.89:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_TRACE(0.00)[panix.com:+] X-Rspamd-Queue-Id: 4d6ZDL66lwz3PhC Ronald Klop writes: > My thought was triggered by this as a build of opendjk11 failed with a > jemalloc error. > https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025-September/804963.html Is this build failure very reproducible? Is there more of a stack trace to go with it? When the jemalloc witness code observes a locking error the process should abort immediately with a SIGABRT. However, there is SIGBUS reported in the build output prior to the witness error which makes it look like OpenJDK may have been handling a signal while the witness code was running. If malloc is somehow being called from a signal handler that is asking for trouble. Here's a closed issue from the old jemalloc repository about a witness error when malloc was called from a signal handler https://github.com/jemalloc/jemalloc/issues/1224 From nobody Thu Nov 13 09:52: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 4d6bCk1xK4z6GbMM; Thu, 13 Nov 2025 09:52:18 +0000 (UTC) (envelope-from ronald@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d6bCk1LRGz3V2r; Thu, 13 Nov 2025 09:52:18 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763027538; 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=xRrsgmuk3lHdJN5ujOb0/oVM7S+2crG+q45Cb6En3u8=; b=JadbRgGHeikrBfW5yo7xj9q58tBiveCeUGhgmHt7/Gfyt6oNbErMyJs6kuZp9bLn7Ll4hr dcWeXeNjXmpeM7tEBv69sHL8DNHp28qRgKQwc5Pvs7RyejTGQSASWb4eSmhY7p8fuEFxB2 uGWOv6dYUcHEhJ9Zmlh1ZJdVuDog/E5oyQ10mxcfpl5zj7ooiGeEuMh3BNuITDj1F0ZiSE 2tYn9CCueuXtZn+UI89fqza2YG4O1O2WddulXEf/yO4gSbELzn+cMsihVr/qszmKmi0Eyh xY0YjodEmOIrsR5Po+5dEngoKTONmzzNFpoQ3vJOlszt2yHhC2yLZLyLO7NIPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763027538; 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=xRrsgmuk3lHdJN5ujOb0/oVM7S+2crG+q45Cb6En3u8=; b=XZM7HJk0VjMAdOmOvc3oSjyQsK2aJUd8N1U8jg3xUMjtHb8RY0jeG2Ual7dnqK2of8OjCX ChALg+paZZ2Wt/AltIRUQPJEZmGpzf3cEchjf/qnabJmHRtf8X3iI2iNaozC+LVjcglhZ9 xvvs7zJbqQgSsP7uiT2cTluHN8Ijr2nHP6IMYBerk8YLSwEZD83H35JTdFRHPGm8zgx6TH Zd/moSd9QM0jLN4ex5WyBAddd5yea0e5ToKI1DLNvG0+68pFpgUwP5BFCwS4jXgP33gGGq 0k5muP2wbz1Z0ZyzXx5shJXkZyUtsJU1+f1DyGBqEWJGSP2onFXEpChUz3OQ7Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763027538; a=rsa-sha256; cv=none; b=RxVAJkXQT6J5EwLnuv/NyEqZmfLyXyWvj9/n+UqKJRNNACO+ip98rxcY00LjzQrXKZUTG1 45EcbRZpzcGDUJa9+x6EbfBbuDGHh1A1eVcKoZprP+4bllIGkwSD9FxD391KqZSAxxKBC6 Ljx7ll3XkeipjXn8SkkNNtkQHGO5MGZNJNPTfng3qs5BO1lnZGh7uHSqLCcVEFQOa1tFJ8 3W6B18JdvN6Sv47rnYr9B+qYzZirHICSRBMfHUktVZMqKG5G9YVGnzkXcAxLlbw0bfx1KZ OUKGL0n5nwivZEH/6lrcBGCZ6eYtHUVJmcqKFLGMJbgpujXcoYrFkoobKWVZvQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2001:1c00:270f:14b0:fd1b:708f:f8d8:f242] (2001-1c00-270f-14b0-fd1b-708f-f8d8-f242.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:270f:14b0:fd1b:708f:f8d8:f242]) (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: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d6bCj4h4Bz17Vq; Thu, 13 Nov 2025 09:52:17 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: <5dd66c4c-ed4d-4034-9fb3-f9079a513595@FreeBSD.org> Date: Thu, 13 Nov 2025 10:52:10 +0100 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 Beta Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld To: Carl Shapiro Cc: bob prohaska , freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> Content-Language: en-US From: Ronald Klop In-Reply-To: <87ldkai9lu.fsf@panix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Op 13-11-2025 om 10:07 schreef Carl Shapiro: > Ronald Klop writes: > >> My thought was triggered by this as a build of opendjk11 failed with a >> jemalloc error. >> https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025-September/804963.html > > Is this build failure very reproducible? Is there more of a stack trace > to go with it? > > When the jemalloc witness code observes a locking error the process > should abort immediately with a SIGABRT. However, there is SIGBUS > reported in the build output prior to the witness error which makes it > look like OpenJDK may have been handling a signal while the witness code > was running. If malloc is somehow being called from a signal handler > that is asking for trouble. > > Here's a closed issue from the old jemalloc repository about a witness > error when malloc was called from a signal handler > > https://github.com/jemalloc/jemalloc/issues/1224 Hi, I only have this example. I don't run armv7 myself. Unfortunately the armv7 pkg builders don't run that often. This is the only failure on main-armv7, but AFAIK no new pkg build run for main-armv7 has happened since. https://portsfallout.com/fallout?port=java%2Fopenjdk&maintainer=&env=armv7&category=&flavor= I just noticed that the full build log is also already gone from the pkg build server. Regards, Ronald. From nobody Thu Nov 13 10:38:08 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 4d6cDh2GTbz6Gf3x; Thu, 13 Nov 2025 10:38:12 +0000 (UTC) (envelope-from mmel@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d6cDh1ZZBz3Zmf; Thu, 13 Nov 2025 10:38:12 +0000 (UTC) (envelope-from mmel@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763030292; h=from:from:reply-to: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=4CbzCq6ugzjZiIVjF+CeaG/EOpwA7+V4K6vhFaw6bzk=; b=u8Ki1pMAI5BsqLkXgFptlV9aj5lGYJDYE6xPyNetanWBu8eVz8pTRNuCXMozrM9ZfVn/gh 8cElvXRe3d0Kbts/KoSYMaGfRNBGL7DNWXQHL71sjlMA71HP11bVkIWyGpeRbD1DEYm1DB TIKiAKPq9WrChwTeexav8CU59ymqTseRJUz5+pMk2aUH0E+oY8swpQRjT0vbE4W1vdIDa5 bInOht+Rz2R77ncPiwQhUZ1xFj1zybrk1e5oz6uYvvpVeUebN8Ikqwv1/cu1XtayaiR+dG ksJLVGgGL3u3eiZY0Bp2s7JHxEz819gg98l8gWO8no31WQ3427UV5CFsgv5QGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763030292; h=from:from:reply-to: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=4CbzCq6ugzjZiIVjF+CeaG/EOpwA7+V4K6vhFaw6bzk=; b=WSe1FPlHqQ6jTl0ioKSBav9bi6bq2c0aRTbrP/hzSE1ppR+9FrSV14EBhB1Sw9gHgUann8 ubi8rNnwSo/OcMXwJ/2R8VcsmT5n3PvKhKVEj+TiD0ELz3HgFBVHtMDYVVj0XFZs1aEh8L aPxRH8kDt6Hwk5oSUWXY5JjmukrsKQVQOcV62ERjBkt6ie06WWli5J/ZPs+gxH+Y8yr/J3 51TQiGtdEuqRFONKrhnlwjhq3u8jSk+0Imj8I27guK0QHAPNPGxVef09+VxyQzNI4iaJNC AUdM6asr5UkZ1VYodh45d0kSVFvl4LD3FUjoUUroaFmTq1rRgp1j+fRpj/2jSg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763030292; a=rsa-sha256; cv=none; b=mY8sZ3e/akivLAE9e4E0tHpXlcZ1IzSlVz6lHSkhvRpR4vnibjfFjjGRiA0orHKygKDIIO 6pZA36a9782HgSqVQYFhjSzFmrHRBqR5Vu5C/nxj8lb20jSWZSxK4XWtA/VWw905GNR8jl 1WmhwAnj6VipOYNoZ+a6ZASKnzE0bWDIS9CKnfaoh9MS0sGaJkKMQQKcS1hsheHOHoLgeD hDP5Qx0DGOhrccj1aWq0H/LlhyBSJTu+ASAHWFlUk/fghKoACpz0DeNQVw2OLcEBsBsp+8 a8T9oXM5bW75tTbo4HkG2cFTRuCOicHshqRKPgHeBcjAKbWTqnXa5YSpOSMPdQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.168.195] (lety.radiolinkplus.cz [109.205.241.143]) (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: mmel/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d6cDg3S1Vz17SJ; Thu, 13 Nov 2025 10:38:11 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Message-ID: <10c8be48-e9cd-4574-868f-51b113159311@FreeBSD.org> Date: Thu, 13 Nov 2025 11:38:08 +0100 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 Reply-To: mmel@FreeBSD.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld To: Ronald Klop , Carl Shapiro Cc: bob prohaska , freebsd-arm@freebsd.org, freebsd-current@freebsd.org References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <5dd66c4c-ed4d-4034-9fb3-f9079a513595@FreeBSD.org> Content-Language: cs, en-US From: Michal Meloun In-Reply-To: <5dd66c4c-ed4d-4034-9fb3-f9079a513595@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 13.11.2025 10:52, Ronald Klop wrote: > Op 13-11-2025 om 10:07 schreef Carl Shapiro: >> Ronald Klop writes: >> >>> My thought was triggered by this as a build of opendjk11 failed with a >>> jemalloc error. >>> https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025- >>> September/804963.html >> >> Is this build failure very reproducible?  Is there more of a stack trace >> to go with it? >> >> When the jemalloc witness code observes a locking error the process >> should abort immediately with a SIGABRT.  However, there is SIGBUS >> reported in the build output prior to the witness error which makes it >> look like OpenJDK may have been handling a signal while the witness code >> was running.  If malloc is somehow being called from a signal handler >> that is asking for trouble. >> >> Here's a closed issue from the old jemalloc repository about a witness >> error when malloc was called from a signal handler >> >> https://github.com/jemalloc/jemalloc/issues/1224 > > > Hi, > > I only have this example. I don't run armv7 myself. > Unfortunately the armv7 pkg builders don't run that often. > > This is the only failure on main-armv7, but AFAIK no new pkg build run > for main-armv7 has happened since. > https://portsfallout.com/fallout? > port=java%2Fopenjdk&maintainer=&env=armv7&category=&flavor= > > I just noticed that the full build log is also already gone from the pkg > build server. > > Regards, > Ronald. I am also a victim of this problem. In my case, unfortunately, the problem is rare and transient. It occurs intermittently and can be resolved by restarting the make. I can confirm that the problem is not related to a specific port. I have experienced it with gdal, qt6-webengine, and rust at minimum. I'm guessing it may be related to memory pressure before OOM. Unfortunately, I'm out of ideas now... Michal From nobody Thu Nov 13 14:41:49 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 4d6jcX2y8Sz6Gy2C; Thu, 13 Nov 2025 14:40:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d6jcW728Fz3Nv2; Thu, 13 Nov 2025 14:40:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5ADEfn0C032888 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 13 Nov 2025 06:41:49 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5ADEfnQe032887; Thu, 13 Nov 2025 06:41:49 -0800 (PST) (envelope-from fbsd) Date: Thu, 13 Nov 2025 06:41:49 -0800 From: bob prohaska To: Carl Shapiro Cc: Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.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: <87ldkai9lu.fsf@panix.com> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d6jcW728Fz3Nv2 On Thu, Nov 13, 2025 at 01:07:41AM -0800, Carl Shapiro wrote: > Ronald Klop writes: > > > My thought was triggered by this as a build of opendjk11 failed with a > > jemalloc error. > > https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025-September/804963.html > > Is this build failure very reproducible? Is there more of a stack trace > to go with it? > All the assertion failures I've seen have been in the clang libraries during buildworld. They appear to happen in a variety of cases, indicated by the different .sh and .cpp filenames found in the files under http://www.zefox.net/~fbsd/assertion_failure/ The failures are random in the sense that restarting buildworld either produces a new assertion failure in a different library or completion. It isn't obvious how to capture a stack trace, if you can provide guidance I'll give it a try. As is, buildworld simply stops, the machine does not crash. Thanks for writing! bob prohaska From nobody Thu Nov 13 15:28:21 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 4d6kgt63hmz6H1hw for ; Thu, 13 Nov 2025 15:28:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.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 4d6kgt4rKmz3V2V for ; Thu, 13 Nov 2025 15:28:42 +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=1763047716; bh=iLqsBwjMjg1aMjRjzb7gp6sWmUePpKQoa4epM1cmshQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=U5GVttHp09Yf/R8APjRA7yDz8kYXRxCvpI+ftaGWpWnjLtI7tc6pkBKwe0XtqV8adF+s5zmdVoA1s+qJLdLJeifDvUGLyVHRvlN+y7aSnW/QxcWoWbsU91Bjy97IKbOBGDc1V+p+gI3BU44UKA9R/Qr4L0/GT64siU1SHbkv4hkt/xDOwg7wQR9HVb4qHRcQ44pnn4BHnuoM3e+qqbomqK51ZKjfyrxC2gOPNbSyEAqPivfKxNuUM4/Y8QiJYzBPlNGxIXGKBoTIb31XyMWIFLmZLabxDS+/sE5n1a+uje4nrMGeufWPs3VW6MSPOpyU5tIx4zGlfvrAUrEY61GFXw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763047716; bh=OsZGlv74kQ/LZz7RhclCEt4H0GeZuRetAO7JUhLFcS6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bXKPqWsWx4rKn3f6KszxjoDJjvOe6H1ZgWGPUQpNM/2HiG1aoaq3sHbMAp/NSZmRSp3VJfTIYKM5y242MOOOHkMWnGoxM8nWp5Fa2A0XuZaS5LNQvGDDa31YE9aOdm6lWR/lS7JmWo5SNBhSEysbgVFEssa3ifWU0NL12Ht9IOZ9onpNcvYWnvmRFV0UwU0doMp526qHsLO9o8yqt+wZ4yyZqtzRdPUKcOH2Oji1MP25ZnTZR9OlrBizEgqQ7yosrmFfEYGy0YkwoZvkabh5qBOI/2DtbweEk9e3citKJmn211wyoCVKLYT4kQZ8qInssi0uIlYVUKv74aKHtVtyuw== X-YMail-OSG: Z9R69NkVM1mq9m6rQV_FSnoElyjWpqKOnr_UVzc4czK9z3KBWbrlxK0ihvpkc72 8j_WUsUXVdH9O6qBZV0nCff82lLT9WVI_Csh7MHjEiOPGvD5XWNFzBpTJm81zuvAlS8F827zEFCw nOfUyCNJ6puED5JJXYvToQhV2AS6paJKfWPr4zPAY683YkS7FY7XoXHGmuuZpKYh9u4AzdMRhciU nsHHUG1uUuiKeuuP5sboq9mpP4Zqnv54J6ATx0tGmFcn82mgBWG782p1ODtYd3.Dc_QHzaGJlNMG Mtjifhq2kjIcFq3ZvUZYCdIEyargAHF4Z2wZmkQWXP76XXCe7E3ad92Njd1HtlD1OoDJDsH8QMcF SQ1V5_sbZBiI2Pwe3LyLSbITtR9fcyaZONLX3DrLZZKn4ay4KmRBG4JSc_LIN7eVf5rqgwRbABFS xOKV4nO9VvPu0aPPTunhuNal8jWphEUGoRg9IUO_4nkJrjcaILWtPPktGdF6y7oYe4lui0Nij03V QhqwyY9ad1KIH81sH43QfrYYFCOgxyoQgf8rN96SyUgJLTLCEBluO04ItS9DUV6.gMQRyUc03fFF GsUMAlu6EJl7fK1IuBpzhRfXpuE5pJ_2EBcBxn7iE2gOo0FXwyAp5rn.U.R3AO40kwE_6I68EV8o JmRGpCd20Z5ta9DjDOo17mbOjT9RWY0_hjyS1Syayu0p04nQEQufgj2yQ_Ko6mtlKEvjDkBll5.s qIEzUDfNyjziopksH2rduu.2Y0mMk0JE9Y_b6l.H_Ujgy2JfqLMgy.njqvnArkQptC1RFqJHO1Z7 Q0MnJ_afs8E0P1ZA_Wtlrwo8N84tRK3UO_e23SIVV7ktCh9bM9y66lx8nT_mvud4Jyy25jausVnL BwJ0NPsWH1it7NOhIWTdwpEr0r06IbulOABNaQXD5CgobYUayeZiYDbD_Zp5go9apWkETHQyk56H Vg42KJl4KX6uAPs3GQQ8jAyLELZKWoWCy1SYZuqgMXNTnpFv5_xQmh2TnVoTJQndppwOheBHVOvr 2mgncYuYxChV5qm.qZEu4kl7.MptbCQN9qlUwZH_gdDuDLDk9RHLMnkPjPXZfHOOB4Jn6kMHSVdp wmE5laLr67WwJXzxa73.8Mk2KddxbRAKARFo1v0EMPiPE4JbfiTYEfALqlkOUpnbBYL9N9x50KZZ jpV2p.q6xN4FnjzJt0u1t6vCtMXda2pv8IUdCIy27NrUfIhJjYCwKBMEPiHbm5RM8DJk9DxInh31 bcEc9mK0M1BktueylN0tlDg4aKfd1mfMTnI04rpeTokKnr9rEJkjks7d6UKHB2b7ucyCKMGdyICe Px1Dc32SWK7eMsYV7_lkiGI77amSPgoHDilwPqIXVC8D_tQy8bnJRyMwFE8XEhRgv3WxrbXj8.JO BhUrxPIjqMCNmtnz_soJN.rEOGM7.t4ebnTwT6UYs2wHKSQ4bKg0efr.IsdvjdqJUa.bDhZ.7MXd PWkm1E69AcJiiiIc1QJiTBk9y5X6elasnq9euTaHfSBTHYlMGrJERSy3o06Yvnle8TfrDj05MxNh RIawv.AJxJnLMxmcXkHOe3dzg68s4jakCkTevd22GoAlDODtbO8Sn0TWs9ohpk2HiJAfonYvscel PPJ1XjzB9kTM5mPc8Y0R3D1dLGYtXESjOsFIcY9qiNc.kC8otWhiFlNMtsBBHCgVG2mexZLG4gwe 7h4spUF2YdnksdAhHnRxwcNA.c2pba.K_L6Zl.w7dHiAUWQhMT87__GwkuGrKr.2olmypJJU9Ta9 GmhCl0IwyHYXgmuqSt0S3xhJTiwopMWMb0715bYY5J_n29G2eaEw16Oae.N1iPtcLmQ68kuTTt.Q S9s814WxXS1n5hmeTodpINl7TDpcE_CCWmh4IhjES4MuTEgJMPJJCKEtAmpej.A2QRFqf2CtFepK 5_AaRdw5DKxDPpE_bSNHunvUAQ6HWscGN1Rx7Urg5pqi2PH_1Xavgg7cfv2PYUY5UThaZWB1xdTo 0E5YDb3f5GmE2xdKqnETL2TRR_71jHbC9ZgFiPtJsMCaZ4VoVlrIlUsqPQQJLAcPZj0mZIfuJv3V GyOwNnzMJfxcLWwq3WCGQcL5kPLX2mvocefYhgJY7AR_xNQMe9ATAh43m6gZGHVPQRfaegx4sns5 YcDm7MVclBVL2TyVrmv4IkTgxlVZxtTla6YRJR8h9WbK6zPC1yCBY2B0Wj9KcXUV1TDxg3dO.6xu 4b18i25M92V867aJHGQrKubn_nJVqJACYVw3TIBI3HRjMcCARZ0D4SyHhKUqUGdudUAP2Q.mGTVL itFNTeQ-- X-Sonic-MF: X-Sonic-ID: 51d469fb-a1b2-4db8-8b31-2b5e680d8c85 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 13 Nov 2025 15:28:36 +0000 Received: by hermes--production-gq1-76c986f798-s298z (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b49b2cb0b65a05ef5a981b36f818448f; Thu, 13 Nov 2025 15:28:32 +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.700.81\)) Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld From: Mark Millard In-Reply-To: <5dd66c4c-ed4d-4034-9fb3-f9079a513595@FreeBSD.org> Date: Thu, 13 Nov 2025 07:28:21 -0800 Cc: Carl Shapiro , bob prohaska , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <38D21887-678B-4AE3-80B4-245ACCC697BB@yahoo.com> References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <5dd66c4c-ed4d-4034-9fb3-f9079a513595@FreeBSD.org> To: Ronald Klop X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d6kgt4rKmz3V2V On Nov 13, 2025, at 01:52, Ronald Klop wrote: > Op 13-11-2025 om 10:07 schreef Carl Shapiro: >> Ronald Klop writes: >>> My thought was triggered by this as a build of opendjk11 failed with = a >>> jemalloc error. >>> = https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025-September/8049= 63.html >> Is this build failure very reproducible? Is there more of a stack = trace >> to go with it? >> When the jemalloc witness code observes a locking error the process >> should abort immediately with a SIGABRT. However, there is SIGBUS >> reported in the build output prior to the witness error which makes = it >> look like OpenJDK may have been handling a signal while the witness = code >> was running. If malloc is somehow being called from a signal handler >> that is asking for trouble. >> Here's a closed issue from the old jemalloc repository about a = witness >> error when malloc was called from a signal handler >> https://github.com/jemalloc/jemalloc/issues/1224 >=20 >=20 > Hi, >=20 > I only have this example. I don't run armv7 myself. > Unfortunately the armv7 pkg builders don't run that often. >=20 > This is the only failure on main-armv7, but AFAIK no new pkg build run = for main-armv7 has happened since. > = https://portsfallout.com/fallout?port=3Djava%2Fopenjdk&maintainer=3D&env=3D= armv7&category=3D&flavor=3D armv7 is tier 2 and so does not have the guarantee: "Official binary packages or third party software will be provided by the ports team." It turns out that various armv7 builder activities have been suspended as of the tier 1's having to deal with 13.5, 14.3, 15.0, and main for latest and quarterly on the same builder machines that otherwise would also be building all that for armv7 as well. It is tied to how long it takes for the 3 ampere*'s to do builds and how few builders there are vs. the count of variations built: large latencies between rebuilds, well beyond just how long the specific prior build took because of other builds that also take a long time. https://people.freebsd.org/~dbaio/pkg-master-report.html shows the most recent builds for armv7 latest and quarterly ending at about: freebsd:13:armv7:32:el:eabi:hardfp latest 2025-10-05 04:47:33Z freebsd:15:armv7:32:el:eabi:hardfp latest 2025-09-26 05:59:09Z (for = prerelease) freebsd:14:armv7:32:el:eabi:hardfp latest 2025-09-23 04:16:17Z freebsd:13:armv7:32:el:eabi:hardfp quarterly 2025-09-16 08:07:05Z freebsd:14:armv7:32:el:eabi:hardfp quarterly 2025-09-03 11:10:32Z (Sending to the world's distribution servers was after those times.) The kmods_* builds are separate and armv7 are still built with the others. But kmods_* cover an incomplete subset of the full set of kernel specific port-packages, if I understand right. > I just noticed that the full build log is also already gone from the = pkg build server. Side note on use of: https://people.freebsd.org/~dbaio/pkg-master-report.html Clicking column titles in the order of "subsorts the next title to be clicked" allows control the overall subsort order across the columns. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Nov 13 22:01:37 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 4d6vPg5yXXz6GJln for ; Thu, 13 Nov 2025 22:01:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4d6vPg1FzXz4MkH for ; Thu, 13 Nov 2025 22:01:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=AB+q5aQJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.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=1763071313; bh=TL9LebERitteEyPrglPuSBijPRdiVqsstSD5/c3TK/s=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=AB+q5aQJZYp0y0HSBe72ApVYllNWrYpuNGtrpd42ZBpWQM4hfjaJGPcK2LRiVjJxyS8X0vojhoHLuc9ApTPBilMFdrOe7C6ffoFQCz1YrFCPh8X8O7C9S63CoiQ197bPZ+Aw70YHsO2MCwOvND0qacdefIsmoB5HyzQAI5SzauuIIE1qDlfndF/+e1yFaH9RcnbxvrffBd4VniR0djZyyLlLz1j8dtumzltODL8OwxEvFwvS3VHkSqpF9bPX2km6KinOJAwUFzbU4PLfbZOjroec47k34fk0gmYk+Xyzv8dgWKkCMgEEYLkrbsAqZk/9DnaWWPLD21Jrs7yJ3Tv8Lg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763071313; bh=PL8tn6g06rgHo78JLjw5odb+ZOuzsSso8i+/RN9UsS9=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=sOd6Yd8Sx8CthG51+FI9L8kNzZceWVFRlMkrshiVOvinCY27Gd+b46C3OcgI1UHa8UYQAbPZmn9kuQUFqje9KYrJnTZVoH2OqBTl55cRbCyWeQJu5dhruQccAZ2pcuWPzuVHeonBV/jwVpMaddqTj5pAlJ1MX2doVgQLTDvPOmcqtoYB860b5Rz/3GpY7sLBR9RIAzUUgMP8A7SQF1iaD5g0oMm9MdJVGs3nGpTUkzOoyS6ipqxDPWaPywfBmFWCrffFHGLiLbvj1mmKTQ0Jf0NMxtLfBOF/sl6Xb+C6gdYkQhYiGKWKqyFy9D2FmcjDAcTOw3fsCUyb24tGwt4vzA== X-YMail-OSG: Shtex0AVM1lIRGv8dUY9VLVb2.QQah_zpC4ozibCDmoRguDVHyKScAEHl3uhil0 rIyXfGbc6T1gYpSpwMXZfCmGQnDu4uo7.8oV9vLGHmXJB8l22_HpFKV5mehjZFLdOLBJerCHu6MR IcaRYtcod7E8HPn1VDJwcqX_CpzBWdGbgp1.SClKUS6Z7nCE1Z3Yh_C3f.7vOWAYy3_zZpOe3dIK nafN3vI0En01njDFPPmTf1CxPHLKmXYhb0KD2_hNQdddsbKdkQgZH3BLkF7D49y0yiModOkJikip cQWC2frIV2vUhtVxcHrOt5uGifl3LAtBtBHuL.0CHpNk1HgRf_YTCXMDcA56_ZRxQtYaN64pes8o 0neolgiDJfkKfvwTCZu2rw2W46nQlVERO5s9hyFddHC.k6qQkmXuWdnu0VUfTTwpos5SxePJW6_k RamwZR3tyAjrgy5mRaU_vXtlIGJyONMJaoZKwT2P3BObWq3DHAmSSMYnQC7dzS6wt5VbHYi.oGaY w.cLJVoeJTErP1oTA_H0399oRIpmTJAGwJu5gBj.mdqd2zd4i2o21MhqCZX0QIW0gb6JVQnmHGc2 gri_cyvsCdN55B8ywJnDzL9Po1ncp4yVfhJTf7JJT7IikadAPXmgjSGUS5deNprtDERHhpy.HPug IEx1Z4n3oWvMUpzUNg.spDzeG.W9w70ir1GkbsjVyWz8SZSZ9NpuJnDFKDyZMzeokvm95Awb8t6V 7CtHidSysFGuB4CuM__Nw_QdWpYBidqECQD7cjrKibOMiFKXZzAwp1kpZf6N3jyNTuCX78OmUVte apciGl0j5eN8fmtR191GfoBhKX5Pt2TWTeZlpq1Wgb.e2uP_zx7NCG0jXTUlVhZaluMS7pOMAaNi MeLEf6VnWKtV3Ptt7XCxPiF5Sa2taJn3VA2ZjA3rDLhOhEwk_o2o9jz5sZOtaOd1duoLetCaOypY mu21qaoaVuabOLY8vqqC1.R1.tkj2tx6gBlpx.zYDfgy2sKScbJ1A5nQdPtvVM74Op4VvNALwHk1 RWOZ0xTgiQeCI9DupCnUoOieJFYaIBEp5LuM9Qw8IXYduo9CGvcRkTSvh8EZmPf6X3Cbvuh4Wkqn CtXs_eGWLdc8nWsmrgwfSxfka1TR_FAvMq2QbDJ014BcANowxfbip6OAoh.z6uBY9CjEvaBOPdRF L73f9nrcgW94cbS5ztuZT34e6Sp3kdol.ZDwi.2Gm9qrVa0_5r7yoG2PLkyNDp.AqTb9Xi4ZtCce Q2a4sc0dJ7t794orwDyIXfKY8Uw1lcir8Re8IVQ5csvk7ei7..n5wY1nVgkD5uZTJbEOc7Xw9Pj3 M8zijXQvB4ZIA2RIZMcXu8Kkh.TUwo8_6UyJEFjTj8fUXqPyGmMLmwDa48qVzF5nMjli7aTTQj8p T8UR5FAVM0gUQvBm4n5q5KAce0nVO2ccroqSmefiqAC.fxQexyeUxfbRgWp1lmvjnIAUKXe20F9z WkI7LFa3sQhQG5Xz3viramusb9FWPcO2UgwQv8R41X_cgghpyfs7OiRGxzUcy2O9gT01TUVMhRgo csBxNGEKSASf6me0nBeafXQ.sukA.g2TKo1ZrJl3t19B_1G8c91N0B7.pk963JDMQZq_4l8QFHHj M16CzWLE419TyS.G3_s5cGQt2nOrrZHC_9vb0vwR90HRUYKpmiE..IrgBmsR_UVYh5BpwwaedEE7 NUrvEQvmlRoGL.hk3YUsF9CvyVQOR0T9.VEKrS0NhvjacUYYbH45F7w0f0.YROIQMxDbV3AWu5Xf YPqKPsWkXM.i2prxP8DaZjiZvsMMcFM5ERr_LCso6GilJPziaeZNOrLU1YkDQFbRqOsRsfEhgSuX D1bj8uMLwWj74npJUbOORTe94DkuMGxJsDa1tIFkfRi0qGxD2ASRHcCk.vyopRtH1Ruetc2H45p1 xwG6tCUyuvWYvphEAb_Qyn12f2YI4snXd1i204BrXSPPA4.8u8GZIMO5_GinZI_BpkYOVeEgGPZu .BZJn28JoGX_ZK.XdkucDOEK9e8m6qBZfeAs3M2SHgIIdrZ_ppN1oc8EhesMGeECB8GcrDgrrQ4T QrE7mr6200_pY19PE_iEzoigwnTUlZTgEAUpI6NeJLi5cDnC8FTy4hOe76rNqaPvPO_CLQs0EFit ziEHmSMuQ8bxmzS6UFgPID26pvCDNgLxUVnNqLZwWScLV4F9Ao25VeFjOK6Uoywf.gEWwgKtlMHh gccF530ejiFIj7bu2lGQmZsMhnVSnAkqtze5qE_QsDaAzzfVFAGV4hSbui7ZHZGrPXiQ_atlSrfY .XmdHe6c- X-Sonic-MF: X-Sonic-ID: f25b705a-56d9-47c9-b643-bec22d58637d Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 13 Nov 2025 22:01:53 +0000 Received: by hermes--production-gq1-76c986f798-g4b5v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5a0e89c044530e79e4d2c6283c9a0d24; Thu, 13 Nov 2025 22:01:48 +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.700.81\)) Subject: native armv7 for struct aiocb offsets and overall size vs. aarch64 for struct aiocb32 offsets and overall size: most fields do not match Message-Id: Date: Thu, 13 Nov 2025 14:01:37 -0800 To: FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-arm X-Mailer: Apple Mail (2.3826.700.81) References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; NEURAL_HAM_SHORT(-0.98)[-0.978]; 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]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from] X-Rspamd-Queue-Id: 4d6vPg1FzXz4MkH The evidence is copied from: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290962#c8 which I just added there. Title (but line-split) for the bugzilla submital was: armv7 chroot and lib32 use on aarch64: example fio command works on real armv7 system boots but fails for aarch64-to-armv7 chroot or lib32 use The evidence: kgdb on armv7 for struct aiocb offsets vs. kgdb on aarch64 for struct aiocb32 offsets (through first few differences): kgdb on armv7 for struct aiocb offsets : (kgdb) ptype /o *(struct aiocb*)0 /* offset | size */ type = struct aiocb { /* 0 | 4 */ int aio_fildes; /* XXX 4-byte hole */ /* 8 | 8 */ off_t aio_offset; /* 16 | 4 */ volatile void *aio_buf; /* 20 | 4 */ size_t aio_nbytes; . . . /* total size (bytes): 104 */ vs.: kgdb on aarch64 for struct aiocb32 offsets : (kgdb) ptype /o *(struct aiocb32*)0 /* offset | size */ type = struct aiocb32 { /* 0 | 4 */ int32_t aio_fildes; /* 4 | 8 */ uint64_t aio_offset; /* 12 | 4 */ uint32_t aio_buf; /* 16 | 4 */ uint32_t aio_nbytes; . . . /* total size (bytes): 96 */ === Mark Millard marklmi at yahoo.com From nobody Thu Nov 13 23:32:14 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 4d6xPt2KxHz6GRTm for ; Thu, 13 Nov 2025 23:32:18 +0000 (UTC) (envelope-from bz@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d6xPt0KNXz3R6r; Thu, 13 Nov 2025 23:32:18 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763076738; 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=7CjuovYoPidOf4IW8eLT8sNHfNYItLqFrkX/IYkKYpA=; b=qZc7wDBrqY5jZtn+QDQAftnNBp56KSnEf4NyWOtYDlhQxuce4/mcKBIqv4tZqlX9x70Y7X dW+Ix0LNjC9DVDyxs+d9OlXr7furr85t+ijlMQz9ddDv/vzsDBlBFDvxujx/FDicg8ZlUr dqyHZ7QN93xuCwpO+xSdAaKHoyaBoIANRSiJCMDTh6StUYAIc+EU8EyCFtNrqdujxjBS8e vJz+nerI6Aj0UHJhVpjp/Ag28VpFenT0OYYP2G6e1/LAlgKEmgVqGUXU1izaAGolAoAXJw UWEqYkxnsIUU8VlofOLhS1kSTiPlCyEdexegtWuMb/50i+y8jnH9x8pkxVyQHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763076738; 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=7CjuovYoPidOf4IW8eLT8sNHfNYItLqFrkX/IYkKYpA=; b=PSTrBZ+8meC/ynDt44Lhw8snQG+1X1Z+4YJuUDlEK2LVyXzsz0iv8PgU2Qga6NK+nTBx32 Qbl/Xgz2o9aqaU7EmVVQ8DK1bsVz0+MpkHU1EjFo9GR9/CxfLcFCHFG0VLgOWoBeAFlXqV ODEnvFm2uGtHEq+j24y9Qz0bWYdmZiktw/Oegu+5VvQTL3/CkVLsmXt/uVD5H/YPURT+9t eN5dh3XkjgLdq7Dw3ei4IJde478K9utXXa9+WIvzVTi3jCk6buhNqBmAidah4rEoWkhNMi pJn88DjqtX3hSRkOJS7zJJ67AADFjh0LZm6GOw6q3jNpLeTLJ7r62jfVVpMC4g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763076738; a=rsa-sha256; cv=none; b=DBC6bSVV2YoqFgcYd1cKaNyPOArkoB1VOro8Pnfh6/4q92eKXh6zdsxi0d8uYq7tFIb30b WWalIq4PGRfP/mT68OWDt9pWNexcFt0RNMVbioL+MYY0J1ssTG0cZrmfuFgIeHIr90JalV G1VLBgaA/CUCewV+S07nYoga+0ASHyBNWwQ0zrQRXncyQRJBB518sCBWnSxf5e34obRoDg AlqPqnwZZE3i26dbOBq+x4EuX4iaXw1j9fthSV8rKnfNHEp7j261D68kG6xX0xJHk/vjap 0+uHWOwBUVpeXnVFDKhDQVHNkkRTzowSfdpt04UScZdTR8g+VpxVLJB0HB+Xfg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 "E8" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d6xPs6BrYzBw3; Thu, 13 Nov 2025 23:32:17 +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 D0E23A64805; Thu, 13 Nov 2025 23:32:03 +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 109D72D029E6; Thu, 13 Nov 2025 23:32:16 +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 uaKkFFrNrOyj; Thu, 13 Nov 2025 23:32:15 +0000 (UTC) Received: from nv.t4-02.sbone.de (nv.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:22]) (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 262002D029D8; Thu, 13 Nov 2025 23:32:14 +0000 (UTC) Date: Thu, 13 Nov 2025 23:32:14 +0000 (UTC) From: "Bjoern A. Zeeb" To: Andriy Gapon cc: Ed Maste , FreeBSD Current Subject: Re: keyboard in wrong mode after VT switch from X In-Reply-To: Message-ID: <95rrq49q-911r-q1r1-n151-1r276n0rq69@mnoonqbm.arg> References: 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 Wed, 12 Nov 2025, Andriy Gapon wrote: > On 12/11/2025 21:38, Ed Maste wrote: >> On Wed, 12 Nov 2025 at 11:15, Andriy Gapon wrote: >>> >>> I usually work in desktop (X11) environment all the time, but recently I >>> had to >>> troubleshoot a problem with Xorg configuration and had to switch between X >>> and a >>> text console quite a bit. And quite frequently (but not always) the >>> keyboard >>> seemed to be in wrong mode after a switch. At least, that's how it >>> appeared: >>> most key presses wouldn't get through, but some (I think Enter) would have >>> an >>> effect. Switching to another text console and back always fixed the >>> input. >> >> I think I've seen this sort of thing being caused by incorrect >> modifier key state - that is, it's acting as if ctrl and/or alt are >> being pressed. If you get in this state again try pressing and >> releasing modifier keys to see if that clears it up. If so, it's a bit >> of an unfortunate workaround but at least will provide a hint for next >> debugging steps. > > Yes, that was it. > I've just repro-ed the issue and pressing Alt helped to restore the input. That's really good to know; I've seen this for years when I end a startx session and get back to VT2 I always had to switch to VT1 and back before Ctrl+d would work (or others) as I usually want to logout. I'll give it a try in a few days (unless a panic happens sooner). It never bothered me enough as it usually only get into this when I shutdown my system for updates. /bz -- Bjoern A. Zeeb r15:7 From nobody Fri Nov 14 03:44:55 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 4d730B50Z1z6Gp4d; Fri, 14 Nov 2025 03:43:54 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d730B1tqhz48jn; Fri, 14 Nov 2025 03:43:54 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AE3itq4035871 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 13 Nov 2025 19:44:55 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AE3itvB035870; Thu, 13 Nov 2025 19:44:55 -0800 (PST) (envelope-from fbsd) Date: Thu, 13 Nov 2025 19:44:55 -0800 From: bob prohaska To: Ronald Klop Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@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: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d730B1tqhz48jn On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote: > Op 12-11-2025 om 23:25 schreef bob prohaska: > > For lack of any better ideas I've collected some of the assertion failure > > /tmp files by host at > > http://www.zefox.net/~fbsd/assertion_failure/ > > > > Thanks for reading, > > > > bob prohaska > > > > > > A really uneducated guess, but might the update of jemalloc [1] have introduced some subtle issues on armv7? > You can try reverting: https://cgit.freebsd.org/src/commit/?id=c43cad87172039ccf38172129c79755ea79e6102. > What is the required syntax? Trying a simple root@generic:/usr/src # git revert -m 1 c43cad87172039ccf38172129c79755ea79e generated a torrent of conflict reports The source tree is expendable with no valued customizations. Thanks for your help, bob prohaska From nobody Fri Nov 14 07:16:56 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 4d77k36TJ0z6H71M; Fri, 14 Nov 2025 07:16:59 +0000 (UTC) (envelope-from cshapiro@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (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 4d77k24Khwz3Xqn; Fri, 14 Nov 2025 07:16:58 +0000 (UTC) (envelope-from cshapiro@panix.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=NmuO2Dnt; dmarc=pass (policy=none) header.from=panix.com; spf=pass (mx1.freebsd.org: domain of cshapiro@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=cshapiro@panix.com Received: from css-ThinkPad-T14s-Gen-2a (c-73-231-159-157.hsd1.ca.comcast.net [73.231.159.157]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4d77k13dScz48fW; Fri, 14 Nov 2025 02:16:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1763104618; bh=HNr+H9g0HLCRPAA61UIozIZwEcxB2yeEpYQTKD2YzGY=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=NmuO2DntFZANBQFCEsRKcyxE7YTuwZO9qXhRdU9euejIx9yeZlzzm9gPRN5TQitbj 3hHpq/9fFObB65EbAudGxjtIKB8vO7dEn5jWU8Rt81DlrcVG3QC8CLsMALL1DhVz+k o8DPYWGorknJeQM0HStibwjsCyh+hiFH0KTAXVdY= From: Carl Shapiro To: bob prohaska Cc: Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld In-Reply-To: (bob prohaska's message of "Thu, 13 Nov 2025 06:41:49 -0800") References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> Date: Thu, 13 Nov 2025 23:16:56 -0800 Message-ID: <877bvthymv.fsf@panix.com> User-Agent: Gnus/5.13 (Gnus v5.13) 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 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.14 / 15.00]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.936]; DMARC_POLICY_ALLOW(-0.50)[panix.com,none]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; R_SPF_ALLOW(-0.20)[+ip4:166.84.1.64/26:c]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[166.84.1.89:from]; RCVD_IN_DNSWL_LOW(-0.10)[166.84.1.89:from]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[panix.com:+] X-Rspamd-Queue-Id: 4d77k24Khwz3Xqn bob prohaska writes: > All the assertion failures I've seen have been in the clang libraries during > buildworld. They appear to happen in a variety of cases, indicated by the > different .sh and .cpp filenames found in the files under > http://www.zefox.net/~fbsd/assertion_failure/ Do you have the stdout and stderr of the build somewhere in there as well? The make(1) invocation in the readme file shows its output being redirected to a file. The assert you mentioned in the subject of your e-mail message, which I also saw in the readme file, could come from jemalloc. See these lines of code for the context https://github.com/facebook/jemalloc/blob/dev/src/extent.c#L805-L814 That assertion will be tripped when jemalloc sees non-zero memory that it expects to be zeroed. See for example https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L55-L106 Looking at the code, my hypothesis would be that jemalloc thinks it's committing memory for the first time but the memory is coming back with non-zero data. Just curious, but is over-commit enabled on your system? Here is the signal jemalloc is using to check https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L729-L737 > The failures are random in the sense that restarting buildworld either > produces a new assertion failure in a different library or completion. > > It isn't obvious how to capture a stack trace, if you can provide guidance > I'll give it a try. As is, buildworld simply stops, the machine does not > crash. It might be captured for you already? I noticed files with names containing "symbolizer-input" and "symbolizer-ouput" like this one http://www.zefox.net/~fbsd/assertion_failure/hostname_pelorus.zefox.org/symbolizer-output-7282d9 and the output files contain a stack trace like this llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:731:7 llvm::sys::RunSignalHandlers() /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:0:5 SignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 Any idea who or what is creating those files and when? From nobody Fri Nov 14 07:31: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 4d78372K94z6H7tN; Fri, 14 Nov 2025 07:31:47 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (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 4d783539rJz3ZSj; Fri, 14 Nov 2025 07:31:45 +0000 (UTC) (envelope-from herbert@gojira.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=MBO0001 header.b=tyTzX4A2; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 80.241.56.171 as permitted sender) smtp.mailfrom=herbert@gojira.at Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (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 mout-p-201.mailbox.org (Postfix) with ESMTPS id 4d78301khdz9v5S; Fri, 14 Nov 2025 08:31:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gojira.at; s=MBO0001; t=1763105500; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nF3O7JFqS47eCUiYvJ2P/QEFXEyQZQ4z0eMK9svWUhQ=; b=tyTzX4A2Mcv1nSIZZTfBiMIj2wrYq4uqVK7uPesquAB8MVDGLsZV7BjR3zlSAfhDsK0CMW CDBYUV8gphcaX20n2OgHInN7hbsRwVPT2JoALzAYh4C0peLn0DqWYH92mUyt+XixVzXQvH Is6aUslua8CEqcN2UE8NFkRqeHV4jnd3rRcQEZWglp332ocC+I7TLAaut82z+aWAmue+qw EkqsKv9Es2zoXT/JlW2qoHcy5F84VRjn4UcbNyshFSyRkfKODaWciX35WeX/JOBXIrCZpl ZddOU2yp3K7wP3P+2jaj9n2D3e/BByKhHEcjkNp3I6J+HKf48DWOzMV78G6POQ== Date: Fri, 14 Nov 2025 08:31:26 +0100 Message-ID: <87ldk9f4tt.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld In-Reply-To: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@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 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gojira.at:s=MBO0001]; R_SPF_ALLOW(-0.20)[+ip4:80.241.56.0/21]; RCVD_IN_DNSWL_LOW(-0.20)[80.241.56.171:from,2001:67c:2050:b231:465::2:received]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:199118, ipnet:80.241.56.0/21, country:DE]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[gojira.at]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gojira.at:+] X-Rspamd-Queue-Id: 4d783539rJz3ZSj On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska wrote: > > On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote: > > Op 12-11-2025 om 23:25 schreef bob prohaska: > > > For lack of any better ideas I've collected some of the assertion failure > > > /tmp files by host at > > > http://www.zefox.net/~fbsd/assertion_failure/ > > > > > > Thanks for reading, > > > > > > bob prohaska > > > > > > > > > > A really uneducated guess, but might the update of jemalloc [1] have introduced some subtle issues on armv7? > > You can try reverting: https://cgit.freebsd.org/src/commit/?id=c43cad87172039ccf38172129c79755ea79e6102. > > > What is the required syntax? Trying a simple > > root@generic:/usr/src # git revert -m 1 c43cad87172039ccf38172129c79755ea79e > generated a torrent of conflict reports > The source tree is expendable with no valued customizations. Try: git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 From nobody Fri Nov 14 12:50:54 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 4d7H7X04jBz6GNPL; Fri, 14 Nov 2025 12:51:04 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4d7H7V2lnlz47Xq; Fri, 14 Nov 2025 12:51:02 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=T1uN0zsq; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 87.255.56.188 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws Received: from smtp-relay-int-backup.realworks.nl (crmpreview8.colo2.realworks.nl [10.2.52.38]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4d7H7M0lByz5H; Fri, 14 Nov 2025 13:50:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1763124655; 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=BXHXO96dWpzzJXvun5jqBMD9m7Z6Krt8Tj5rQPkqFDI=; b=T1uN0zsqujunr1NuXlDJ/lWZMylPhyKsgv0ayNtxERL2ZrUEKuDY5lIBAnxVkt2F+ojtVc LLhm0WhaCK/w4mhtlE/ivjtmh8eNdXL4zyeO+xTlAhMQn+AK9AS2n/r4CMm68HV4y3S3MT bsB1y36fEKzTYB85z1kfTz0HEYeuvQYvx10sW2+tZfxig8eRpmo7o/aeEi0BvkU3u3riwU ETtI9OlT1I0G5F64so6VSRaHt30s53k0+73a2IjfgMkUbYutICvFiPO+0i1e6fqvMc/N/l UJcYcxwgITPoYLhoQxyp8mEUjAcng4l8TUdFEaMvPnW75jnZMdyb1Lupi1mCJg== Received: from crmpreview8.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview8.colo2.realworks.nl (Postfix) with ESMTP id 6A4AB2C04C8; Fri, 14 Nov 2025 13:50:54 +0100 (CET) Date: Fri, 14 Nov 2025 13:50:54 +0100 (CET) From: Ronald Klop To: mmel@FreeBSD.org Cc: Ronald Klop , bob prohaska , freebsd-current@freebsd.org, Carl Shapiro , freebsd-arm@freebsd.org Message-ID: <562279.6155.1763124654329@localhost> In-Reply-To: <10c8be48-e9cd-4574-868f-51b113159311@FreeBSD.org> References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <5dd66c4c-ed4d-4034-9fb3-f9079a513595@FreeBSD.org> <10c8be48-e9cd-4574-868f-51b113159311@FreeBSD.org> Subject: openjdk11 compile fail on armv7 - (Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) 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/alternative; boundary="----=_Part_6154_1449500835.1763124653925" X-Mailer: Realworks (773.19) X-Originating-Host: from (83-81-212-149.cable.dynamic.v4.ziggo.nl [83.81.212.149]) by crmpreview8.colo2.realworks.nl [10.2.52.38] with HTTP; Fri, 14 Nov 2025 13:50:54 +0100 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:145.0) Gecko/20100101 Firefox/145.0 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; R_SPF_ALLOW(-0.20)[+ip4:87.255.56.128/26]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[klop.ws:+] X-Rspamd-Queue-Id: 4d7H7V2lnlz47Xq ------=_Part_6154_1449500835.1763124653925 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Michal Meloun Datum: donderdag, 13 november 2025 11:38 Aan: Ronald Klop , Carl Shapiro CC: bob prohaska , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Onderwerp: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld > > > On 13.11.2025 10:52, Ronald Klop wrote: > > Op 13-11-2025 om 10:07 schreef Carl Shapiro: > >> Ronald Klop writes: > >> > >>> My thought was triggered by this as a build of opendjk11 failed with a > >>> jemalloc error. > >>> https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025- >>> September/804963.html > >> > >> Is this build failure very reproducible? Is there more of a stack trace > >> to go with it? > >> > >> When the jemalloc witness code observes a locking error the process > >> should abort immediately with a SIGABRT. However, there is SIGBUS > >> reported in the build output prior to the witness error which makes it > >> look like OpenJDK may have been handling a signal while the witness code > >> was running. If malloc is somehow being called from a signal handler > >> that is asking for trouble. > >> > >> Here's a closed issue from the old jemalloc repository about a witness > >> error when malloc was called from a signal handler > >> > >> https://github.com/jemalloc/jemalloc/issues/1224 > > > > > > Hi, > > > > I only have this example. I don't run armv7 myself. > > Unfortunately the armv7 pkg builders don't run that often. > > > > This is the only failure on main-armv7, but AFAIK no new pkg build run > for main-armv7 has happened since. > > https://portsfallout.com/fallout? > port=java%2Fopenjdk&maintainer=&env=armv7&category=&flavor= > > > > I just noticed that the full build log is also already gone from the pkg > build server. > > > > Regards, > > Ronald. > > I am also a victim of this problem. In my case, unfortunately, the problem is rare and transient. It occurs intermittently and can be resolved by restarting the make. I can confirm that the problem is not related to a specific port. I have experienced it with gdal, qt6-webengine, and rust at minimum. > > > I'm guessing it may be related to memory pressure before OOM. Unfortunately, I'm out of ideas now... > > Michal > > > > I was able to reproduce openjdk11 failure in an armv7 poudriere build on aarch64 Raspberry Pi. The build doesn't always fail and the output is not always the same. Here is the output of two different compile runs. [00:19:54] === Output from failing command(s) repeated here === [00:19:54] * For target jdk_modules_java.base__the.java.base_batch: [00:19:54] # [00:19:54] # A fatal error has been detected by the Java Runtime Environment: [00:19:54] # [00:19:54] # SIGBUS (0xa) at pc=0x2031ce84, pid=34578, tid=124336 [00:19:54] # [00:19:54] # JRE version: OpenJDK Runtime Environment (11.0.11+9) (build 11.0.11+9-1) [00:19:54] # Java VM: OpenJDK Server VM (11.0.11+9-1, mixed mode, g1 gc, bsd-) [00:19:54] # Problematic frame: [00:19:54] # C [libc.so.7+0x1ace84] _malloc_thread_cleanup+0xa43c [00:19:54] # [00:19:54] # Core dump will be written. Default location: /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/java.core [00:19:54] # [00:19:54] # An error report file with more information is saved as: [00:19:54] # /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/hs_err_pid34578.log [00:19:54] # [03:09:57] === Output from failing command(s) repeated here === [03:09:57] * For target support_jmods_java.sql.jmod: [03:09:57] # [03:09:57] # A fatal error has been detected by the Java Runtime Environment: [03:09:57] # [03:09:57] # SIGBUS (0xa) at pc=0x2169d0c4, pid=16567, tid=137017 [03:09:57] # [03:09:57] # JRE version: OpenJDK Runtime Environment (11.0.29+7) (build 11.0.29+7-1) [03:09:57] # Java VM: OpenJDK Server VM (11.0.29+7-1, mixed mode, serial gc, bsd-) [03:09:57] # Problematic frame: [03:09:57] # J 77 c2 java.io.DataInputStream.readUnsignedShort()I java.base (39 bytes) @ 0x2169d0c4 [0x2169cf40+0x00000184] [03:09:57] # [03:09:57] # Core dump will be written. Default location: /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/jmod.core [03:09:57] # [03:09:57] # An error report file with more information is saved as: [03:09:57] # /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/hs_err_pid16567.log This is in a poudriere build that does not leave the environment behind after a failure. This weekend I can try to run poudriere with the options to keep the jail alive and gather some more artifacts for people to analyze. What kind of info would be valuable? The *.core and the hs_err*.log file maybe. Regards, Ronald. ------=_Part_6154_1449500835.1763124653925 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Michal Meloun <mmel@FreeBSD.org>
Datum: donderdag, 13 november 2025 11:38
Aan: Ronald Klop <ronald@FreeBSD.org>, Carl Shapiro <cshapiro@panix.com>
CC: bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org, freebsd-current@freebsd.org
Onderwerp: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld



On 13.11.2025 10:52, Ronald Klop wrote:
> Op 13-11-2025 om 10:07 schreef Carl Shapiro:
>> Ronald Klop <ronald@FreeBSD.org> writes:
>>
>>> My thought was triggered by this as a build of opendjk11 failed with a
>>> jemalloc error.
>>> https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025- >>> September/804963.html
>>
>> Is this build failure very reproducible?  Is there more of a stack trace
>> to go with it?
>>
>> When the jemalloc witness code observes a locking error the process
>> should abort immediately with a SIGABRT.  However, there is SIGBUS
>> reported in the build output prior to the witness error which makes it
>> look like OpenJDK may have been handling a signal while the witness code
>> was running.  If malloc is somehow being called from a signal handler
>> that is asking for trouble.
>>
>> Here's a closed issue from the old jemalloc repository about a witness
>> error when malloc was called from a signal handler
>>
>> https://github.com/jemalloc/jemalloc/issues/1224
>
>
> Hi,
>
> I only have this example. I don't run armv7 myself.
> Unfortunately the armv7 pkg builders don't run that often.
>
> This is the only failure on main-armv7, but AFAIK no new pkg build run > for main-armv7 has happened since.
> https://portsfallout.com/fallout? > port=java%2Fopenjdk&maintainer=&env=armv7&category=&flavor=
>
> I just noticed that the full build log is also already gone from the pkg > build server.
>
> Regards,
> Ronald.

I am also a victim of this problem. In my case, unfortunately, the problem is rare and transient. It occurs intermittently and can be resolved by restarting the make. I can confirm that the problem is not related to a specific port. I have experienced it with gdal, qt6-webengine, and rust at minimum.


I'm guessing it may be related to memory pressure before OOM. Unfortunately, I'm out of ideas now...

Michal
 


I was able to reproduce openjdk11 failure in an armv7 poudriere build on aarch64 Raspberry Pi.
The build doesn't always fail and the output is not always the same. Here is the output of two different compile runs. 
[00:19:54] === Output from failing command(s) repeated here ===
[00:19:54] * For target jdk_modules_java.base__the.java.base_batch:
[00:19:54] #
[00:19:54] # A fatal error has been detected by the Java Runtime Environment:
[00:19:54] #
[00:19:54] #  SIGBUS (0xa) at pc=0x2031ce84, pid=34578, tid=124336
[00:19:54] #
[00:19:54] # JRE version: OpenJDK Runtime Environment (11.0.11+9) (build 11.0.11+9-1)
[00:19:54] # Java VM: OpenJDK Server VM (11.0.11+9-1, mixed mode, g1 gc, bsd-)
[00:19:54] # Problematic frame:
[00:19:54] # C  [libc.so.7+0x1ace84]  _malloc_thread_cleanup+0xa43c
[00:19:54] #
[00:19:54] # Core dump will be written. Default location: /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/java.core
[00:19:54] #
[00:19:54] # An error report file with more information is saved as:
[00:19:54] # /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/hs_err_pid34578.log
[00:19:54] #



[03:09:57] === Output from failing command(s) repeated here ===
[03:09:57] * For target support_jmods_java.sql.jmod:
[03:09:57] #
[03:09:57] # A fatal error has been detected by the Java Runtime Environment:
[03:09:57] #
[03:09:57] #  SIGBUS (0xa) at pc=0x2169d0c4, pid=16567, tid=137017
[03:09:57] #
[03:09:57] # JRE version: OpenJDK Runtime Environment (11.0.29+7) (build 11.0.29+7-1)
[03:09:57] # Java VM: OpenJDK Server VM (11.0.29+7-1, mixed mode, serial gc, bsd-)
[03:09:57] # Problematic frame:
[03:09:57] # J 77 c2 java.io.DataInputStream.readUnsignedShort()I java.base (39 bytes) @ 0x2169d0c4 [0x2169cf40+0x00000184]
[03:09:57] #
[03:09:57] # Core dump will be written. Default location: /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/jmod.core
[03:09:57] #
[03:09:57] # An error report file with more information is saved as:
[03:09:57] # /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/hs_err_pid16567.log

This is in a poudriere build that does not leave the environment behind after a failure. This weekend I can try to run poudriere with the options to keep the jail alive and gather some more artifacts for people to analyze.

What kind of info would be valuable? The *.core and the hs_err*.log file maybe.

Regards,
Ronald.
  ------=_Part_6154_1449500835.1763124653925-- From nobody Fri Nov 14 13:15: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 4d7HhZ46Cnz6GPxB for ; Fri, 14 Nov 2025 13:16:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 4d7HhZ2lgDz3FTp for ; Fri, 14 Nov 2025 13:16:14 +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=1763126168; bh=2s8FIlSZTajT2wx3tGHSFNMZrXuR6iZHqTo0AkjtQg8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=U+zSoZCnFCuV2xhApntV8uadtVwkLLEZ0E/pJJSjGj3QAd1WcONHSz12oXdKrW1JTBdM5HIvDHZW07ilhhePmlkzMe6oPg2h712XhFszEP7AQwozCWNbiqNMHD+HqlJf9o8/JQgq0LAvK/D3ygWU+x+SBcjFKR74z9eG8R0jd2C5vbVZ/AO4cpMp7GlOvmqeURXI0CqQcqggfQoe8lhIoTjxtdVcPf/kx7MZMTaLXbYj9wBcBrq6BWENlRDdsCLTKt2RlwvynTkSXUlleLKpC8abAl0seVc7xfPBaDc5xsyh1cnVykCbACqyZAqdGhdtuOHEJK525B1FrV12RZ1mlw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763126168; bh=IZwBh7oq/vJPVTTX5edsmKJwP1nulsk4G7Kpf5vzGzG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Bqzxvd/w3t9ieJX6qnjzofCVCSTRqnbqIq+/3rT1da5FtKy9ORHsPdeP/RzaW9bU5GPN54sz2mtde/lbA9c0e7GVU8leeMVj2MlzqZ8sD0YC3+A7XOQrltUt9HX15h+jatRSujjzWxo21YNucMfLRbU2IUZVDRVTNEGojyocfykXt4omp0zEXwtgbWNEAatRZzbKhiOAoEKMD6+1nhVzmFEZoDUwkxi5mGiQtKx7CTxlPyVBVHYsrn1sgu8zw2YkJK3yc+x4OtAwIO+XxFT/LNjZ+ijDBotIMn8zrYKgHXXYmGjpZJr6cR+04shaN6ezmnwN++7nrPe0cAdgZUCpIA== X-YMail-OSG: 5HZd3FAVM1lNtrDkUStYpSImBi1iYY8ErdulgLjHbLID5Wd796ji4BX4sybI85G QVDndC_14UNfRRO3PSysDjtexjyoDZcKzMCLFAhRlwPWBE_PMttevGggc5npeQXOgWPmpK2ZaLvw LubmEbp.Ll8hydEvvy8o1h8wUorDaM_JYdquLex7nd6mWQ.K0hsIcosb4TMYDPFcMs4Gq3kzkpv3 VCyh7jB9feCzeY.LcS7y_zLSEIZnkx12nWmlIw1Q7oEgCEmt8c62ywE0SWilEZfrC0El0l_qipf. TL55X3B2YIqCBI9QtFkfB8KK7UpRjL_WCUTqeHRttWx8oN_z2yuJfnZMiQr3DZnI2pRiPck0SW2o 2Q6TjfGGLHrJJYorZnS4utbEcrtcnA4wG9NaN0DgQubp7IXUqiYbDfHILiyKO5cYK74jpPaHShs3 raFiUTkliK4UIZtFFdsIfCXtnM6PHUcodVXOpTyHIELSInCjlN_w1oPjqpG2FxvIYNfFqCXTeHYH GQ83yOHjtOJG9mLuamIrkxh3Y1qGYYl1q3aazsIUFd5GEXTXpuvSInul7i1M1eHBOdv708bueLMl DsjoS4uB2msYc4LvkTFskSkXsc1oVJu_qzZBsG84sMfE8Y3rhZD8xttGNU694EmajgC3FE5UNvz1 bqyNHeQV8GAi.FUWmwiz0gBuEBcQmyY2g8xT3.HcDQJEx1YL_xt9S2tW2z6BRK3EZUR.mvZgGXMk U3d7XdAqFRX8f6sQj5uJhk.Vu.FHnlfmxgpUel7Exsby6Eunw0jcKw3ov5xdnt41G8aXgByQ8gWf XIF8NSmSK_NFQ6TXuIN53LWm9oY_wZMrAAIYpBx_gMdPgD7KaZxsEh46BTZbwYF.tE40DwK.lwV_ VYU8YbcyMAvqlKV5sXXjDoXiRBiOfYaFYcVuRx0Ag1ggAdF94omi.A1t_e8IsniSR4os8xgBQCNm HQm8.cuZ_uu4QZn9oBgfCj5iGIn4wd80riO9aeLt_yOuqYu1DZkr2C9fMoqwyu9KW_v29YuIDRcS NEpGVNt4DxFnp.t08PtbIcHie3tO4CBU79ra4K2lhnlWFE3h.ln2MxAG9wNZiO5ygXRTNv4DeJfD wpHPAazwlnm.RMQwNcH40_v4yQKyyrLfxoi9qiedmjvq3np1.9ieh0F9E3gdFEI1FZC9Uxv4gAlU VhyRgkI41AVCSwrJ7uUp1Gy_bBAwlqs3TV_6U3o4eNBSOPfDWvROsh9AdLARqAR0LpkleD_KIMDu bJaA.aC3Vt1GQz9gkHyCUEq0z64sg9FNbFtYKQuKRlXT53YOWsVUJ1AITZfalPez0J3RflPF2Kha mLhLE81sNYpsFPxtc4mdqlj_BRQRIQVkImZz1IGbi4p6.XimsOwo1Wwo1nBDnsGcmSM2_2mprp10 1NCssdzRTlrSTiKdFH__KaXKk4N3.S4uIvdxz0DX5YJkNFNua8rdCDPK1HFwLVWaYiJfc1wUgRxg H3JjTlj2Axr9fwnXv14Nz16owhnOMtgPmpVmx15QCRUtnblrIjyPAhAoo8GDjlJrluB_IiG_b6S6 7zZZT7K.x_ge98u8YH2GLIl7GVlnnnHaaYs1HbdXMFOV.WdAEzjxpL26CBRBvSLNo5x0dITyNTSa tDRbLHKNwScQhJ04UbX7T7taR1Souwe8ZSPyDce3sQhB15hLRjM5AlZEyHviyGqv8zAUjGBPqpzC qXoeromVRpxrwKmD3m7nIzP0y6gOMOLYuHcFpc5wIIWA5Oms_BNFyqjYaNf7YnFzYGBk87Ljk1Bx 1S_62S9tZrDatw9HVRNeua6CjH2ukWv4tlnFLaHGI5Yif2WPI9MgZdPEOAs7.HYCdvifBNn59fr4 qd26.c5TdgCmgmqujv7gJXScF4L1eGEbRDVDCiAkN8LvjxCvdVahxTYjeVCLOe3jWOVxVa_YxId7 JOrAAG0qxnx8xqrJlv2uhLAFnbbv.ltBTIVPUAgEeEe6dUJpKc0mrnjysQQobV8gX2JBRti76rKp 60QCUQF78lXYKpC2j2lrfwDdm4L.SVhPB1GpCDf306w2_z.xZSN_x1jrCfL4sQ3kTwhIqJHS3AJY 57pXR4SLjVJIoAannP44FuHGWqQJQNqk_ni.fYcgMb9auOu.9.VBwiYQ6Zz5PJCemckCpF3q3fZR GilnySLx2eZ1Kjo6_zq_R96a_XQpqbAFA4rzn2CcYj6MlhCJmGomIxaemKVEL4RwuPNnG.DkT4Y9 9VC48bUkE.Q2wIZHxPNhS8bibQOrosDFy1QcuzXwB37o.Aw6TzSd2uEyhkU881HkwL2zjGcWzbd7 a06dCahM- X-Sonic-MF: X-Sonic-ID: aa31afe4-6b9e-4139-9400-efbc9224fa9e Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Nov 2025 13:16:08 +0000 Received: by hermes--production-gq1-76c986f798-n7lp5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c803e95b636707069e2908be7fe314ca; Fri, 14 Nov 2025 13:16:03 +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.700.81\)) Subject: Re: openjdk11 compile fail on armv7 - (Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld) From: Mark Millard X-Priority: 3 (Normal) In-Reply-To: <562279.6155.1763124654329@localhost> Date: Fri, 14 Nov 2025 05:15:52 -0800 Cc: "mmel@freebsd.org" , Ronald Klop , bob prohaska , freebsd-current@freebsd.org, Carl Shapiro , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2ECC872F-CA50-40C6-A2DD-7ED8DEE49BAD@yahoo.com> References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <5dd66c4c-ed4d-4034-9fb3-f9079a513595@FreeBSD.org> <10c8be48-e9cd-4574-868f-51b113159311@FreeBSD.org> <562279.6155.1763124654329@localhost> To: Ronald Klop X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d7HhZ2lgDz3FTp On Nov 14, 2025, at 04:50, Ronald Klop wrote: > Van: Michal Meloun > Datum: donderdag, 13 november 2025 11:38 > Aan: Ronald Klop , Carl Shapiro = > CC: bob prohaska , freebsd-arm@freebsd.org, = freebsd-current@freebsd.org > Onderwerp: Re: Still seeing Failed assertion: "p[i] =3D=3D 0" on armv7 = buildworld >=20 >=20 > On 13.11.2025 10:52, Ronald Klop wrote: > > Op 13-11-2025 om 10:07 schreef Carl Shapiro: > >> Ronald Klop writes: > >> > >>> My thought was triggered by this as a build of opendjk11 failed = with a > >>> jemalloc error. > >>> https://lists.freebsd.org/archives/freebsd-pkg-fallout/2025- >>> = September/804963.html > >> > >> Is this build failure very reproducible? Is there more of a stack = trace > >> to go with it? > >> > >> When the jemalloc witness code observes a locking error the process > >> should abort immediately with a SIGABRT. However, there is SIGBUS > >> reported in the build output prior to the witness error which makes = it > >> look like OpenJDK may have been handling a signal while the witness = code > >> was running. If malloc is somehow being called from a signal = handler > >> that is asking for trouble. > >> > >> Here's a closed issue from the old jemalloc repository about a = witness > >> error when malloc was called from a signal handler > >> > >> https://github.com/jemalloc/jemalloc/issues/1224 > > > > > > Hi, > > > > I only have this example. I don't run armv7 myself. > > Unfortunately the armv7 pkg builders don't run that often. > > > > This is the only failure on main-armv7, but AFAIK no new pkg build = run > for main-armv7 has happened since. > > https://portsfallout.com/fallout? > = port=3Djava%2Fopenjdk&maintainer=3D&env=3Darmv7&category=3D&flavor=3D > > > > I just noticed that the full build log is also already gone from the = pkg > build server. > > > > Regards, > > Ronald. >=20 > I am also a victim of this problem. In my case, unfortunately, the = problem is rare and transient. It occurs intermittently and can be = resolved by restarting the make. I can confirm that the problem is not = related to a specific port. I have experienced it with gdal, = qt6-webengine, and rust at minimum. >=20 >=20 > I'm guessing it may be related to memory pressure before OOM. = Unfortunately, I'm out of ideas now... >=20 > Michal > =20 >=20 > I was able to reproduce openjdk11 failure in an armv7 poudriere build = on aarch64 Raspberry Pi. > The build doesn't always fail and the output is not always the same. = Here is the output of two different compile runs. [00:19:54] =3D=3D=3D = Output from failing command(s) repeated here =3D=3D=3D > [00:19:54] * For target jdk_modules_java.base__the.java.base_batch: > [00:19:54] # > [00:19:54] # A fatal error has been detected by the Java Runtime = Environment: > [00:19:54] # > [00:19:54] # SIGBUS (0xa) at pc=3D0x2031ce84, pid=3D34578, tid=3D124336 > [00:19:54] # > [00:19:54] # JRE version: OpenJDK Runtime Environment (11.0.11+9) = (build 11.0.11+9-1) > [00:19:54] # Java VM: OpenJDK Server VM (11.0.11+9-1, mixed mode, g1 = gc, bsd-) > [00:19:54] # Problematic frame: > [00:19:54] # C [libc.so.7+0x1ace84] _malloc_thread_cleanup+0xa43c > [00:19:54] # > [00:19:54] # Core dump will be written. Default location: = /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/java.co= re > [00:19:54] # > [00:19:54] # An error report file with more information is saved as: > [00:19:54] # = /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/hs_err_= pid34578.log > [00:19:54] # >=20 >=20 >=20 > [03:09:57] =3D=3D=3D Output from failing command(s) repeated here =3D=3D= =3D > [03:09:57] * For target support_jmods_java.sql.jmod: > [03:09:57] # > [03:09:57] # A fatal error has been detected by the Java Runtime = Environment: > [03:09:57] # > [03:09:57] # SIGBUS (0xa) at pc=3D0x2169d0c4, pid=3D16567, tid=3D137017 > [03:09:57] # > [03:09:57] # JRE version: OpenJDK Runtime Environment (11.0.29+7) = (build 11.0.29+7-1) > [03:09:57] # Java VM: OpenJDK Server VM (11.0.29+7-1, mixed mode, = serial gc, bsd-) > [03:09:57] # Problematic frame: > [03:09:57] # J 77 c2 java.io.DataInputStream.readUnsignedShort()I = java.base (39 bytes) @ 0x2169d0c4 [0x2169cf40+0x00000184] > [03:09:57] # > [03:09:57] # Core dump will be written. Default location: = /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/jmod.co= re > [03:09:57] # > [03:09:57] # An error report file with more information is saved as: > [03:09:57] # = /wrkdirs/usr/ports/java/openjdk11/work/jdk11u-jdk-11.0.29-7-1/make/hs_err_= pid16567.log >=20 >=20 > This is in a poudriere build that does not leave the environment = behind after a failure. This weekend I can try to run poudriere with the = options to keep the jail alive and gather some more artifacts for people = to analyze. There is the "poudriere bulk" is the option: -w Save WRKDIR on build failure. The WRKDIR will be tarred = up into ${POUDRIERE_DATA}/wrkdirs. I have a /wrkdirs/usr/ports/ that I use for creating /wrkdirs/usr/ports/*/*/ and expanding the archive. I do that to have the same path as seen in the builder jail. However, sometimes there are materials that are outside the area tar'd ( such as the builder's /tmp/ ). So live sessions can have required uses. > What kind of info would be valuable? The *.core and the hs_err*.log = file maybe. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 14 15:25:27 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 4d7LXP2qVrz6GbX5; Fri, 14 Nov 2025 15:24:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d7LXN6VWWz3csn; Fri, 14 Nov 2025 15:24:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AEFPRXt038077 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 14 Nov 2025 07:25:28 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AEFPR40038076; Fri, 14 Nov 2025 07:25:27 -0800 (PST) (envelope-from fbsd) Date: Fri, 14 Nov 2025 07:25:27 -0800 From: bob prohaska To: Carl Shapiro Cc: Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.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: <877bvthymv.fsf@panix.com> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d7LXN6VWWz3csn On Thu, Nov 13, 2025 at 11:16:56PM -0800, Carl Shapiro wrote: > bob prohaska writes: > > > All the assertion failures I've seen have been in the clang libraries during > > buildworld. They appear to happen in a variety of cases, indicated by the > > different .sh and .cpp filenames found in the files under > > http://www.zefox.net/~fbsd/assertion_failure/ > > Do you have the stdout and stderr of the build somewhere in there as > well? The make(1) invocation in the readme file shows its output being > redirected to a file. Those files have been overwritten by restarting the buildworld sessions. They tend to be large and diffcult to synchronize with the .cpp and .sh files generated by the crash. It could be done if it's useful. > > The assert you mentioned in the subject of your e-mail message, which I > also saw in the readme file, could come from jemalloc. See these lines > of code for the context > > https://github.com/facebook/jemalloc/blob/dev/src/extent.c#L805-L814 > > That assertion will be tripped when jemalloc sees non-zero memory that > it expects to be zeroed. See for example > > https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L55-L106 > > Looking at the code, my hypothesis would be that jemalloc thinks it's > committing memory for the first time but the memory is coming back with > non-zero data. > > Just curious, but is over-commit enabled on your system? Here is the > signal jemalloc is using to check > > https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L729-L737 > Sysctl -a reports in part: # sysctl -a | grep -i overcommit sysctl: S_vmtotal 48 != 88 vm.overcommit: 0 # It's unclear if this implies yes or no, or even is the correct test. > > The failures are random in the sense that restarting buildworld either > > produces a new assertion failure in a different library or completion. > > > > It isn't obvious how to capture a stack trace, if you can provide guidance > > I'll give it a try. As is, buildworld simply stops, the machine does not > > crash. > > It might be captured for you already? I noticed files with names > containing "symbolizer-input" and "symbolizer-ouput" like this one > > http://www.zefox.net/~fbsd/assertion_failure/hostname_pelorus.zefox.org/symbolizer-output-7282d9 > > and the output files contain a stack trace like this > > llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) > /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:731:7 > > llvm::sys::RunSignalHandlers() > /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:0:5 > > SignalHandler > /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 > > handle_signal > /usr/src/lib/libthr/thread/thr_sig.c:0:3 > > Any idea who or what is creating those files and when? The files are deposited in /tmp, apparently by the C compiler as records of an internal error in the compiler, usually number 134. My understanding is superficial at best. Thanks for writing! bob prohaska From nobody Fri Nov 14 15:45: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 4d7Lzr4zLZz6GdBC; Fri, 14 Nov 2025 15:44:40 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d7Lzr1lWsz3gh4; Fri, 14 Nov 2025 15:44:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AEFjkYT038146 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 14 Nov 2025 07:45:47 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AEFjjuw038145; Fri, 14 Nov 2025 07:45:45 -0800 (PST) (envelope-from fbsd) Date: Fri, 14 Nov 2025 07:45:45 -0800 From: bob prohaska To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> 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: <87ldk9f4tt.wl-herbert@gojira.at> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d7Lzr1lWsz3gh4 On Fri, Nov 14, 2025 at 08:31:26AM +0100, Herbert J. Skuhra wrote: > On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska wrote: > > > > On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote: > > > Op 12-11-2025 om 23:25 schreef bob prohaska: > > > > For lack of any better ideas I've collected some of the assertion failure > > > > /tmp files by host at > > > > http://www.zefox.net/~fbsd/assertion_failure/ > > > > > > > > Thanks for reading, > > > > > > > > bob prohaska > > > > > > > > > > > > > > A really uneducated guess, but might the update of jemalloc [1] have introduced some subtle issues on armv7? > > > You can try reverting: https://cgit.freebsd.org/src/commit/?id=c43cad87172039ccf38172129c79755ea79e6102. > > > > > What is the required syntax? Trying a simple > > > > root@generic:/usr/src # git revert -m 1 c43cad87172039ccf38172129c79755ea79e > > generated a torrent of conflict reports > > The source tree is expendable with no valued customizations. > > Try: > > git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 > git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 > git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 > Looks like something fundamental is wrong: root@generic:/usr/src # git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 contrib/jemalloc/INSTALL.md: unmerged (9701364041c8858d188ba80e629ed33a6ecda67d) contrib/jemalloc/INSTALL.md: unmerged (90da718d2b6aae8964fdcf35e2ab751fa1b62110) contrib/jemalloc/INSTALL.md: unmerged (b8f729b0d790f3af09f1519314a69057b08a8384) contrib/jemalloc/Makefile.in: unmerged (121297702bccc022853e46d46903199b18ac46bc) contrib/jemalloc/Makefile.in: unmerged (1193cd859c49c027647f2747d77bb8cfe0444d20) contrib/jemalloc/Makefile.in: unmerged (7128b007ec05359bc88e14615c34e00883ace8b2) contrib/jemalloc/TUNING.md: unmerged (500541dd52d05f9edf0e690273be190116520d26) contrib/jemalloc/TUNING.md: unmerged (e96399d7c9b8916297f6530c2b37a7f43ff1651b) contrib/jemalloc/TUNING.md: unmerged (34fca05b4325035505a6292031c58c8b3f95720f) contrib/jemalloc/bin/jeprof.in: unmerged (dc2c3ea877b8597b5622976a02c4f5518377aebc) ... error: your index file is unmerged. fatal: revert failed root@generic:/usr/src # git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 contrib/jemalloc/INSTALL.md: unmerged (9701364041c8858d188ba80e629ed33a6ecda67d) contrib/jemalloc/INSTALL.md: unmerged (90da718d2b6aae8964fdcf35e2ab751fa1b62110) contrib/jemalloc/INSTALL.md: unmerged (b8f729b0d790f3af09f1519314a69057b08a8384) contrib/jemalloc/Makefile.in: unmerged (121297702bccc022853e46d46903199b18ac46bc) contrib/jemalloc/Makefile.in: unmerged (1193cd859c49c027647f2747d77bb8cfe0444d20) contrib/jemalloc/Makefile.in: unmerged (7128b007ec05359bc88e14615c34e00883ace8b2) contrib/jemalloc/TUNING.md: unmerged (500541dd52d05f9edf0e690273be190116520d26) contrib/jemalloc/TUNING.md: unmerged (e96399d7c9b8916297f6530c2b37a7f43ff1651b) contrib/jemalloc/TUNING.md: unmerged (34fca05b4325035505a6292031c58c8b3f95720f) contrib/jemalloc/bin/jeprof.in: unmerged (dc2c3ea877b8597b5622976a02c4f5518377aebc) ... error: your index file is unmerged. fatal: revert failed root@generic:/usr/src # git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 contrib/jemalloc/INSTALL.md: unmerged (9701364041c8858d188ba80e629ed33a6ecda67d) contrib/jemalloc/INSTALL.md: unmerged (90da718d2b6aae8964fdcf35e2ab751fa1b62110) contrib/jemalloc/INSTALL.md: unmerged (b8f729b0d790f3af09f1519314a69057b08a8384) contrib/jemalloc/Makefile.in: unmerged (121297702bccc022853e46d46903199b18ac46bc) contrib/jemalloc/Makefile.in: unmerged (1193cd859c49c027647f2747d77bb8cfe0444d20) contrib/jemalloc/Makefile.in: unmerged (7128b007ec05359bc88e14615c34e00883ace8b2) contrib/jemalloc/TUNING.md: unmerged (500541dd52d05f9edf0e690273be190116520d26) contrib/jemalloc/TUNING.md: unmerged (e96399d7c9b8916297f6530c2b37a7f43ff1651b) contrib/jemalloc/TUNING.md: unmerged (34fca05b4325035505a6292031c58c8b3f95720f) contrib/jemalloc/bin/jeprof.in: unmerged (dc2c3ea877b8597b5622976a02c4f5518377aebc) ... error: your index file is unmerged. fatal: revert failed root@generic:/usr/src # Have I got a corrupted source tree? Or, more likely, did I misunderstand your suggestion? Thanks for writing! bob prohaska From nobody Fri Nov 14 17:16: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 4d7P2l4p7Qz6GnJL for ; Fri, 14 Nov 2025 17:17:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (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 4d7P2l3Mczz3vjT for ; Fri, 14 Nov 2025 17:17:19 +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=1763140633; bh=Me8+ff5Lk+E7Ksxauz/VjF2Rf3D4utgpQWA0NbDIY0c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=rS2SFo3BMQmUfCHjG8oTwz74eBabEmH1OFq5jNw7CMC/2Y8kI0cGcuYeCpD79qfX0aoWBUp0AcgGiUVgW+rgcC/L3kAqnrtTVUkauJGZolsynNENWH8dOKM10ME4xEpzVHe5Sb5SHUUvyiRaHNo5Gc9aA1MaVKhEJxfkl47Fmbgcm9nhSXwCDE1kVqshg4c/8bEXstj+iCE1FIhv3TFbMwUhgP5uVUCqUx/FdTXKkAtLLrGw50SXrABbdnIHMvXoM3bpdGh0vKZvuzOOfvUftsIek7Coaz+xAqhVspplvdaOjJ83jK1cJ4L0Od601TWji8Q1QNuidImXzeD2pm58Eg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763140633; bh=HMgk9FBjJ8RXOiZ+kgdGkwdANCMTnD0b68nBodv1VUK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cQxqgiBl0CgxZrJloBtXOPP8HqZJK9Gah7UiI6l6vT84mLNaWaTYtRhqV1sH0ZA/JqyA8mk/t/KlF9yrBaMBzuvUxIYpF2bk5qZJ7zp0x92tBDVMaiMhLrc0jPKke6pp6SucBaM7bHXOcqwlx+aMx5aon2DCXsLsuipMgbenwAt6rWTyh9P9w6vfq2o5srylERjmzD0iqladqME5/UTPcbewH3zb7p+x2MWJlbDqm6jEmsgIl2dgO89WXxsluJr/VLDG1DySV0Wv7iZgWwJBgxeQcfUI37MifnCbtwuK/uIqXwiqA9wRes3l+R+5+kINZwyvO2hVKUahPiLXUoJnmw== X-YMail-OSG: qxG7x_cVM1mtVfzIFfK8zgccaonwCJHGyct328HMmXlfbr49vS17q7jBhigtQki gCz6NaMwphI6k99SkJwaYWbvuCu1kLJY9KqfPd7LtkjHz7jcjUVpuz3_VtA_oo.QK79pkE4fm0ws VMJXrOsdKsrcYabTN6xI74vzRJjCD3MhTkbr1r9tFZ9GUuTzCSeSQ.KCLiwtKA3ptt_v0JY_NRPe l9qZkXQyD31FHk9_Nqz9mlGLg3789oejedx1fET2iuhOLZHCIxz.Uo11yNysTkf74H7U.b33ABrk cEUTvFkNuB4HFpxoiyVyo2g__RwbmK9BaIy5SZhBEmo7tF19O.c.bEsy8plLD3vswt1YYzmET6Kf quzel9puYLVr407JFBbMyFPNdjcn9JYjrkcysBOjT1437dLzpuzpioosYippxGUsn8vOzZpQNbqw h.jjN97xDbQwpT59eAtlBniLRGUxbDzuhJGHR69rcRyhQm0J8yn_Rz_Q_2lGGXE_M1XBWp0VTY8G vLFSDJppTmKWBB8MgIHwd2tOrRCFHfszSXQV0g.gqM34abFRGpBX54R3B_.de615BA5gLOllVLqw YXItNMyFWlB9KmCoBgZXZ3xtYZxjItA1LbcDytnOi3dQ9gKZXqipiPLKwWF3lq5Lkim3ZS6JGqry x98AX7J1ruUrTXF29PpbS6G4Pv9.HCjNz.r5Wg4L7Doj421WhvK8l83xzh8snPcirVzSvzVi7F8U a2H_rhXl2wAivDFlxY.M82i8K2xPtM4eMnnUhJaUD_KgSwCn6vfZ6FiMHdqp1vbYtv_vQUO.etIW LUTzEaELEJQUDOSBli3BBBEwtaJhR5qZijW7Mnp1kH_biUhJWxRgyF3q__46pv4.qUZlhO5migH5 ZGgmTUiLlRvVM3rXdCtyHzVCUVAzopiJ8Rd7idJ13cKAQkkWlEdW2ovIOMgdHyzd_0LKn96EH5HD eXyOZRBWiZKrCjoSoDo_kb034T5QF3DAyDW.OEXmMZpoZiZA__qAuXCmYLybBIcrrreHVgRp1FVI aG04obJKz5ODC6gM_h.7p8G40aLCn17a84n1It5KCrv99eHarRGjDoG8XATLHd.6C9kCocuMapaY EUCcus7jeiuPNmISlgx.fCHOF.yY1rhmIdfFSu.btors8uJhQkjdU9HvGnNoigJzSuPKMFZShE4L zMwF2FrNuC_0ARRMcQiYQBUuvylafnsFMRC10d1mxerFZWRJtx7hQkb6tkFQm_4iCL9DEBoNbMft WgPB0tItqnzYkpSo_JRnp60oRxHv79Xz8tQ3.9AO4e.LKlnXu4n9xKcgfX6ybmHl7zASOTxHHy9O XCmFBOXWdsxSXBwLprFXd1LHk2mEKl8yHN8dTWrMPqgOvyOKY_klCOepDHOzwmy.SGMb21Ym_ET1 994T2dd3KfJbAt0BfPHPIBgGo88fWTpSl25mA0M3ZJ5r9Nj9U3PfYkoj8rG.A1ev5AldSaN6JGWI ekbGTbv9UINfaL2_mCNmg4_QnpSeP6wAzRsTVNDje.eZkn9pw1HRatoYbcfD32cE8OECBIYTe9IG w4MH4takA_aNARkI1rnvRof3B7FFc8iJ05MBYxk93kM_VhcYgyFrl.SVHg5JgKKHsVXh3LzFZhx3 VIVqAb9Q6rUhAqcnza78XaOZdGb2HqWvAGIFwkgcLN1K54KwkdFBxZdhUu.trs6uw20dGH0kor.v mvgdng7dW1JSquSr5P5e1O9fq7G9KlgDPCAeg8pWApoBwaVLTJlvfeOH2moxDtKViYRR4sVPuccq rJie3p.KGzpUsaBSIwhH2_.eZiAFeQQx1jFGaYBjapdRKRDBOeB.1WePxfYP8cATzgl39ND4UnlY CA3CZCAV3b1znCF0ZsIwz6mebXo6rj8GJq4pZIsB4btEXvqfOLACyT.s2cgJN6aDlQzz41KBvACa YLjVaUFS.D1gmWfrLvC4xuAbLeR4AwcOf0IkkIa5i.eKaEluUUWfKluWeh1U_5khwJ23SqMJEbgf 1hWiMSjezi1a.PEz1z8cqtrgvCJBv7nBJISjUqausLTc62s_L5O15hEzjNkHXPHrOjdbNnaFQ2uJ 2BnhWgYWUIN8.c7ZJj5BrrLipKXnssctbcjR_ViiHVeZgYvwD8zAs6B39tkz_LUzxxOBF2L9.hVU H2T9hgO94TPh80.5ajGlWbnRkcihloZSlYhiLGS7k09Hs15mDStO7B1eWlFtiuSuDor3GNr7F2jA poRp7FZ9S902qh9ze6CblFXm40gV9h0AO0jU- X-Sonic-MF: X-Sonic-ID: 4f8cafc9-6ec7-43bf-9dc4-a5321b6aec1e Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Nov 2025 17:17:13 +0000 Received: by hermes--production-gq1-76c986f798-pjhrg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 08cb25d39aa5967c89a2789bc8399bee; Fri, 14 Nov 2025 17:17:07 +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.700.81\)) Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld From: Mark Millard In-Reply-To: Date: Fri, 14 Nov 2025 09:16:57 -0800 Cc: Carl Shapiro , Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> To: bob prohaska X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d7P2l3Mczz3vjT On Nov 14, 2025, at 07:25, bob prohaska wrote: > On Thu, Nov 13, 2025 at 11:16:56PM -0800, Carl Shapiro wrote: >> bob prohaska writes: >>=20 >>> All the assertion failures I've seen have been in the clang = libraries during >>> buildworld. They appear to happen in a variety of cases, indicated = by the=20 >>> different .sh and .cpp filenames found in the files under >>> http://www.zefox.net/~fbsd/assertion_failure/ >>=20 >> Do you have the stdout and stderr of the build somewhere in there as >> well? The make(1) invocation in the readme file shows its output = being >> redirected to a file. >=20 > Those files have been overwritten by restarting the buildworld = sessions. > They tend to be large and diffcult to synchronize with the .cpp and = .sh > files generated by the crash. It could be done if it's useful. >=20 >>=20 >> The assert you mentioned in the subject of your e-mail message, which = I >> also saw in the readme file, could come from jemalloc. See these = lines >> of code for the context >>=20 >> https://github.com/facebook/jemalloc/blob/dev/src/extent.c#L805-L814 >>=20 >> That assertion will be tripped when jemalloc sees non-zero memory = that >> it expects to be zeroed. See for example >>=20 >> https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L55-L106 >>=20 >> Looking at the code, my hypothesis would be that jemalloc thinks it's >> committing memory for the first time but the memory is coming back = with >> non-zero data. >>=20 >> Just curious, but is over-commit enabled on your system? Here is the >> signal jemalloc is using to check >>=20 >> https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L729-L737 >>=20 >=20 > Sysctl -a reports in part: > # sysctl -a | grep -i overcommit > sysctl: S_vmtotal 48 !=3D 88 The s_vmtotal line above is from what sysctl vm.vmtotal would report: output for "System wide totals computed every five seconds". That S_vmtotal line reported is a internal warning from sysctl. The 88 is correct and is sizeof(struct vmtotal) from sys/sys/vmmeter.h : (kgdb) ptype /o *(struct vmtotal*)0 /* offset | size */ type =3D struct vmtotal { /* 0 | 8 */ uint64_t t_vm; /* 8 | 8 */ uint64_t t_avm; /* 16 | 8 */ uint64_t t_rm; /* 24 | 8 */ uint64_t t_arm; /* 32 | 8 */ uint64_t t_vmshr; /* 40 | 8 */ uint64_t t_avmshr; /* 48 | 8 */ uint64_t t_rmshr; /* 56 | 8 */ uint64_t t_armshr; /* 64 | 8 */ uint64_t t_free; /* 72 | 2 */ int16_t t_rq; /* 74 | 2 */ int16_t t_dw; /* 76 | 2 */ int16_t t_pw; /* 78 | 2 */ int16_t t_sl; /* 80 | 2 */ int16_t t_sw; /* 82 | 6 */ uint16_t t_pad[3]; /* total size (bytes): 88 */ } The 48 is wrong for what the internal sysctl(. . .) returned. The message also indicates that the normal assocaited output was not generated for vm.vmtotal . I do not know if the error is somehow associated with your overlarge swap space (if you still have that). In my context "sysctl vm.vmtotal" and "sysctl -a" are working normally. > vm.overcommit: 0 "man 7 tuning" reports about vm.overcommit : The vm.overcommit sysctl defines the overcommit behaviour of the vm subsystem. The virtual memory system always does accounting of the = swap space reservation, both total for system and per-user. = Corresponding values are available through sysctl vm.swap_total, that gives the = total bytes available for swapping, and vm.swap_reserved, that gives = number of bytes that may be needed to back all currently allocated anonymous memory. Setting bit 0 of the vm.overcommit sysctl causes the virtual memory system to return failure to the process when allocation of memory = causes vm.swap_reserved to exceed vm.swap_total. Bit 1 of the sysctl = enforces RLIMIT_SWAP limit (see getrlimit(2)). Root is exempt from this = limit. Bit 2 allows to count most of the physical memory as allocatable, = except wired and free reserved pages (accounted by = vm.stats.vm.v_free_target and vm.stats.vm.v_wire_count sysctls, respectively). > #=20 > It's unclear if this implies yes or no, or even is the correct test. >=20 >>> The failures are random in the sense that restarting buildworld = either >>> produces a new assertion failure in a different library or = completion. >>>=20 >>> It isn't obvious how to capture a stack trace, if you can provide = guidance >>> I'll give it a try. As is, buildworld simply stops, the machine does = not >>> crash. >>=20 >> It might be captured for you already? I noticed files with names >> containing "symbolizer-input" and "symbolizer-ouput" like this one >>=20 >> = http://www.zefox.net/~fbsd/assertion_failure/hostname_pelorus.zefox.org/sy= mbolizer-output-7282d9 >>=20 >> and the output files contain a stack trace like this >>=20 >> llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) >> = /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:731:7 >>=20 >> llvm::sys::RunSignalHandlers() >> /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:0:5 >>=20 >> SignalHandler >> /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 >>=20 >> handle_signal >> /usr/src/lib/libthr/thread/thr_sig.c:0:3 >>=20 >> Any idea who or what is creating those files and when? >=20 > The files are deposited in /tmp, apparently by the C compiler as = records > of an internal error in the compiler, usually number 134. My = understanding=20 > is superficial at best. =20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 14 19:25:54 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 4d7Rsq6c8jz6H0FF; Fri, 14 Nov 2025 19:24:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d7Rsq2fgFz3GXK; Fri, 14 Nov 2025 19:24:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AEJPsmM038849 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 14 Nov 2025 11:25:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AEJPsGp038848; Fri, 14 Nov 2025 11:25:54 -0800 (PST) (envelope-from fbsd) Date: Fri, 14 Nov 2025 11:25:54 -0800 From: bob prohaska To: Mark Millard Cc: Carl Shapiro , Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.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-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d7Rsq2fgFz3GXK On Fri, Nov 14, 2025 at 09:16:57AM -0800, Mark Millard wrote: > On Nov 14, 2025, at 07:25, bob prohaska wrote: > > > On Thu, Nov 13, 2025 at 11:16:56PM -0800, Carl Shapiro wrote: > >> bob prohaska writes: > >> > >>> All the assertion failures I've seen have been in the clang libraries during > >>> buildworld. They appear to happen in a variety of cases, indicated by the > >>> different .sh and .cpp filenames found in the files under > >>> http://www.zefox.net/~fbsd/assertion_failure/ > >> > >> Do you have the stdout and stderr of the build somewhere in there as > >> well? The make(1) invocation in the readme file shows its output being > >> redirected to a file. > > > > Those files have been overwritten by restarting the buildworld sessions. > > They tend to be large and diffcult to synchronize with the .cpp and .sh > > files generated by the crash. It could be done if it's useful. > > > >> > >> The assert you mentioned in the subject of your e-mail message, which I > >> also saw in the readme file, could come from jemalloc. See these lines > >> of code for the context > >> > >> https://github.com/facebook/jemalloc/blob/dev/src/extent.c#L805-L814 > >> > >> That assertion will be tripped when jemalloc sees non-zero memory that > >> it expects to be zeroed. See for example > >> > >> https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L55-L106 > >> > >> Looking at the code, my hypothesis would be that jemalloc thinks it's > >> committing memory for the first time but the memory is coming back with > >> non-zero data. > >> > >> Just curious, but is over-commit enabled on your system? Here is the > >> signal jemalloc is using to check > >> > >> https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L729-L737 > >> > > > > Sysctl -a reports in part: > > # sysctl -a | grep -i overcommit > > sysctl: S_vmtotal 48 != 88 > > The s_vmtotal line above is from what > > sysctl vm.vmtotal > > would report: output for > > "System wide totals computed every five seconds". > > That S_vmtotal line reported is a internal warning from > sysctl. The 88 is correct and is sizeof(struct vmtotal) > from sys/sys/vmmeter.h : > > (kgdb) ptype /o *(struct vmtotal*)0 > /* offset | size */ type = struct vmtotal { > /* 0 | 8 */ uint64_t t_vm; > /* 8 | 8 */ uint64_t t_avm; > /* 16 | 8 */ uint64_t t_rm; > /* 24 | 8 */ uint64_t t_arm; > /* 32 | 8 */ uint64_t t_vmshr; > /* 40 | 8 */ uint64_t t_avmshr; > /* 48 | 8 */ uint64_t t_rmshr; > /* 56 | 8 */ uint64_t t_armshr; > /* 64 | 8 */ uint64_t t_free; > /* 72 | 2 */ int16_t t_rq; > /* 74 | 2 */ int16_t t_dw; > /* 76 | 2 */ int16_t t_pw; > /* 78 | 2 */ int16_t t_sl; > /* 80 | 2 */ int16_t t_sw; > /* 82 | 6 */ uint16_t t_pad[3]; > > /* total size (bytes): 88 */ > } > > The 48 is wrong for what the internal sysctl(. . .) > returned. The message also indicates that the > normal assocaited output was not generated for > vm.vmtotal . > > I do not know if the error is somehow associated with > your overlarge swap space (if you still have that). > In my context "sysctl vm.vmtotal" and "sysctl -a" > are working normally. The 48 is likely related to having excess swap space. On a machine with 1.77 GB swap the command reports root@www:/usr/src # sysctl -a | grep -i overcommit vm.overcommit: 0 I don't think it's related to the assertion failure, since that host experiences assertion failures as often as hosts with excess swap space. > > > vm.overcommit: 0 > > "man 7 tuning" reports about vm.overcommit : > > The vm.overcommit sysctl defines the overcommit behaviour of the vm > subsystem. The virtual memory system always does accounting of the swap > space reservation, both total for system and per-user. Corresponding > values are available through sysctl vm.swap_total, that gives the total > bytes available for swapping, and vm.swap_reserved, that gives number of > bytes that may be needed to back all currently allocated anonymous > memory. > > Setting bit 0 of the vm.overcommit sysctl causes the virtual memory > system to return failure to the process when allocation of memory causes > vm.swap_reserved to exceed vm.swap_total. Bit 1 of the sysctl enforces > RLIMIT_SWAP limit (see getrlimit(2)). Root is exempt from this limit. > Bit 2 allows to count most of the physical memory as allocatable, except > wired and free reserved pages (accounted by vm.stats.vm.v_free_target and > vm.stats.vm.v_wire_count sysctls, respectively). > > > # > > It's unclear if this implies yes or no, or even is the correct test. I remain uncertain if overcommit is on or off 8-( It seems like overcommit limits are intended to keep one user from exhausting swap on a multiuser host. Not my situation, if that's the case. It can only be said that it's probably whatever is default for -current. The sysctl command above was run as root, as is buildworld. Thanks for writing! bob prohaska From nobody Fri Nov 14 20:14: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 4d7T072wYBz6H3fQ for ; Fri, 14 Nov 2025 20:15:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (using TLSv1.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 4d7T070f5bz3MRh for ; Fri, 14 Nov 2025 20:15:19 +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=1763151312; bh=dj9QTynhtX6bANinEoBFcYKbHmRjJ90pY1I64aW/hSQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BAInMCQipA+UUxJzknYSBdHmWW688MJ1efVfhty0HOZzMejMxM3NRakYeJNB7V0tlFT96URhjJd+6JIg9Qfv3CZvhSHmD8LciVk9bGdoLG2vW+Li/4KDeaV1UJs5MngZApsA0DDyQgM5Ef1Dm7TdwjBXDSW5I1ZwUAbex1Lw0VcW0lu4h5N5kH4hqK29wNFWYgmjHrJG7EDIx7vF3F7hthqlR7xOtxFAU25I8NVq1PUaYQAuIqRJ5I0rBh4O3iHl5KQ/uA+4UFR9AtBncDMjcjv1b+KqrKWbGEPkLA+XjUBNXZzdUZNYhZ+D6K5MVUzkggHbLCNJXaMY7LOSMseDCg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763151312; bh=siuvQKm+Y910O/MxzxIdh3F2UhU3z7wnEqzvtPVJOam=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Juku+8UO81wlPACb3Ibd2ulDINI5bzSiepPtvpRnnGqac2p9eEsfOhMC5lOxPG5u93JlzHZnclhV7ZjWt+QzGwqqOq7yLKqovGHNMEDm4a438WESJvkeRcTtrGtBEN3Z1d7uLaXUgvaJn+NOgvibj1HIzFj5Oa60EBLNG0yXSyFMA59Tw8b93yer+F72ehZvnOTx5MnEZXpYKkS0rpwRl464nbPzC5rgsiTfGapV7vW0w78YjXXUcCl+HyfC/FCIoOmJZ5zTgsc705306HR69MhzTagk0hBLKkqy0Iq5qx1YudWoUR9kxYBVx/Hzql1aGeohmhoxSGq1efmA2GLAZQ== X-YMail-OSG: BaekGIIVM1lGM_c_Pap05HHUl41_7xwpbTm0eLGq48UJ6SxnL_CThXD9bm695Js QgcGIAE.6dGuqmgqt_r5Z3nyOFCeQIs0k5NeMe686NzsFdNzDDeGORLw0W2ROKMnnkJbyWzYUkry Y5mBVkVhIrmew8leIF_UELKHpkLySqag5.olMud2TaqEr9Oqau_z8d2fUEVUl385KqTfwHb7CU5P .Gf0SGhtAVrZ5Klq22hGNwW5fAgIYzAU4wmu5ITngSC8PXXjj7FkEti3sMbjzPQRj1x8dmgq_x3m DVvOahGvgr6nYAocMhewT3thHVhdrdiIfoGIsRNjDvSApEfTW0REJ_uXJ2jsht4ALfD.H19vGbvl I_Bf9JO0CSref.ocgb1DOJsc233neRmb4IHuXC_27tezTW60UvBnsMhuVw3z22FpOrgGJ_ISou6d MXppruZ6gqd9HpBQ_8.S2JAar5jpZFhjMYPWWtzpsxU35AIL1v0Ay_o4ecJvzKDso0N3N4lmHcba lXEUhF44PxJd_Q6sLxMBi4UA48IeKeVV_DBoAB0SErBXGUr3dxVEhwj4Oeagd5lUzmx4XV3gLqAN NQU7AIZ4xaJ6UGtIsOiv8u5VG8jAamqwsyQRk.BgQkdU57dugfL8rthtZssAKwUvCrYEICTiN8YC FPQCd_eZk.bYL6UDswBj7gicnh6nekVGtoPu8NuOgrW_2h8YXyWbfy0Mf.6X0IBKiSsM4pQJ0vW7 9LC.D4YA7gd4SfZC2huo3skWPGbxs4YUQgrFAWDajCwfXzseizIU2oAs4bwccYicnGRoAZgxulN4 Ko.kBTwKM0CeYsEjWxNtBvNn5Aj_7L25TEuBQQCZK.iesPU1selmaaOv_.qsHG9B79hXEQVWB5em l0R.l5AgN1K2sllAPTfsHpksVTiOBf8vkFUxbsgYCBiKXjA0WB0xBVM5awzWT5eN5DDUaaMiE5pS 0i5IO5j8LPGH4PqAurVihJ3B2dtoXxQN4qQQno1xaAreYfQD57QUewuZbSmRWLdqq5k46m.GnXVS 6zfyJXmdNQLjxd1q6DBq7a42eIwFUIquS4ANfazDU966c1bawV.KQkUmYMO7INKm9h2pBojkRROm FaQl2BkpPWDHyUmYJe_FRzDoRcMUJnL5Y3Al7aEPqcEWrmwN5z.dfGYWsgzO5DMKKO5wh7Lchveu 1kOvjaR0xpwVBoVptLmYdDUm.Xy_mupRYKiQ5iPOeTZs9rDk0sWvo_vQy5VNyMDWnvBe0_hw7Ity KzWS3IEiybQRLcep8CJklIBFFNIvJjcGetNhr8L8rTXVrQ5aKmaVI_TtbrVTBnmd7mloKbl_FAVJ 4JOfrRIx87Vd4qtC.b7S1F98IA5aj8CM3jM9BnuKUxvmr7M1rvQnT9VRUQ96v5fojbY1XliGGxQ4 QtUukzzpZIbPaOl40JHEjiJ8TKeo1NERPBBK.4hPHLI9hz0RCkZ5Jcp487AMXp65a3I5j2zFgEcN CdLnjkCd2RGzg8ZjpYQHpPT2hMsvozwxlnQMpgDiJWnlWEzMva0AmYQG6ZPYSTcMD6K_.mUWwP5o fdtBpsN3OgDVTY6f1PSx0u3dzQddShiNY0fnn03EsaoBT.Q62hNeO0d4MrqvWhwn5EJQKHrJG5sA d1yLsxN88SvINcYRDhlkUV608wlzsD4Cj3iUmjoSmOs3dN.QXtG_nk2Z5OUIpAe2lUncPfRFZMPt jMwmGzB4WHnWvNNgcqgbX9SSPgTXHSzp017qdDRAnAZpvs0lOa_59QRFyG36smhguP8R31TB_5w. eg8tFzNd0PfzvzUHL_ywbc1Y7.OtkVLdbX_T5lUgCbcJkihpRMezAfbwMRqLbfNh9cOAH6hfVQI1 HMfMbPYsfUqBB82rt6gGx8mbWUXbfw3Wql3ZeQcbBWdO2SXjQFpYN.vr4TuUOGaCxCfZyDwC8J8n _vv9rhfjTI.a0BgxSZqamNqvk4vZBjB8HswkAsir8NgQuLGc2eauimRPO6R6JSLvKtuR5hZam2jS JimYV6TbEjwijeP48kqCVmmV71GNos08oPeq8nRcrIa7qffIQHobkiYeySyxmvuB8ugQ.3kOUq0r WOpktWVWkia1dS8.3TRtbCKyyeQLTv53e1GBpNgGUp48YZ8p0905k_Th5TXE0t8_.Opdgy_c5Vcz WlHk9Lq8JjuhReCXSFT2.fYgtkx4vxcY0ZyFJGevWmSZaT7V3fHjLrDvf2A2gE_JEHQw139vdK7F MyLj7xZMA4zTbjczxRTNuzdMv12dCsim73oCETqY6pC7zSsDyLnkz4g3.WDMfQ3tci9N40xhQICK bX1zc76A- X-Sonic-MF: X-Sonic-ID: e26c631e-ec12-4bc3-99d4-27f252988368 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 14 Nov 2025 20:15:12 +0000 Received: by hermes--production-gq1-76c986f798-j5tsw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1b5eaa041db4b9b6af84b555f8544876; Fri, 14 Nov 2025 20:15: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.700.81\)) Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld From: Mark Millard In-Reply-To: Date: Fri, 14 Nov 2025 12:14:57 -0800 Cc: Carl Shapiro , Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <08A61538-82A4-4CB0-8610-FF61CDA05EE8@yahoo.com> References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> To: bob prohaska X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d7T070f5bz3MRh On Nov 14, 2025, at 11:25, bob prohaska wrote: > On Fri, Nov 14, 2025 at 09:16:57AM -0800, Mark Millard wrote: >> On Nov 14, 2025, at 07:25, bob prohaska wrote: >>=20 >>> On Thu, Nov 13, 2025 at 11:16:56PM -0800, Carl Shapiro wrote: >>>> bob prohaska writes: >>>>=20 >>>>> All the assertion failures I've seen have been in the clang = libraries during >>>>> buildworld. They appear to happen in a variety of cases, indicated = by the=20 >>>>> different .sh and .cpp filenames found in the files under >>>>> http://www.zefox.net/~fbsd/assertion_failure/ >>>>=20 >>>> Do you have the stdout and stderr of the build somewhere in there = as >>>> well? The make(1) invocation in the readme file shows its output = being >>>> redirected to a file. >>>=20 >>> Those files have been overwritten by restarting the buildworld = sessions. >>> They tend to be large and diffcult to synchronize with the .cpp and = .sh >>> files generated by the crash. It could be done if it's useful. >>>=20 >>>>=20 >>>> The assert you mentioned in the subject of your e-mail message, = which I >>>> also saw in the readme file, could come from jemalloc. See these = lines >>>> of code for the context >>>>=20 >>>> = https://github.com/facebook/jemalloc/blob/dev/src/extent.c#L805-L814 >>>>=20 >>>> That assertion will be tripped when jemalloc sees non-zero memory = that >>>> it expects to be zeroed. See for example >>>>=20 >>>> https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L55-L106 >>>>=20 >>>> Looking at the code, my hypothesis would be that jemalloc thinks = it's >>>> committing memory for the first time but the memory is coming back = with >>>> non-zero data. >>>>=20 >>>> Just curious, but is over-commit enabled on your system? Here is = the >>>> signal jemalloc is using to check >>>>=20 >>>> https://github.com/facebook/jemalloc/blob/dev/src/pages.c#L729-L737 >>>>=20 >>>=20 >>> Sysctl -a reports in part: >>> # sysctl -a | grep -i overcommit >>> sysctl: S_vmtotal 48 !=3D 88 >>=20 >> The s_vmtotal line above is from what >>=20 >> sysctl vm.vmtotal >>=20 >> would report: output for >>=20 >> "System wide totals computed every five seconds". >>=20 >> That S_vmtotal line reported is a internal warning from >> sysctl. The 88 is correct and is sizeof(struct vmtotal) >> from sys/sys/vmmeter.h : >>=20 >> (kgdb) ptype /o *(struct vmtotal*)0 >> /* offset | size */ type =3D struct vmtotal { >> /* 0 | 8 */ uint64_t t_vm; >> /* 8 | 8 */ uint64_t t_avm; >> /* 16 | 8 */ uint64_t t_rm; >> /* 24 | 8 */ uint64_t t_arm; >> /* 32 | 8 */ uint64_t t_vmshr; >> /* 40 | 8 */ uint64_t t_avmshr; >> /* 48 | 8 */ uint64_t t_rmshr; >> /* 56 | 8 */ uint64_t t_armshr; >> /* 64 | 8 */ uint64_t t_free; >> /* 72 | 2 */ int16_t t_rq; >> /* 74 | 2 */ int16_t t_dw; >> /* 76 | 2 */ int16_t t_pw; >> /* 78 | 2 */ int16_t t_sl; >> /* 80 | 2 */ int16_t t_sw; >> /* 82 | 6 */ uint16_t t_pad[3]; >>=20 >> /* total size (bytes): 88 */ >> } >>=20 >> The 48 is wrong for what the internal sysctl(. . .) >> returned. The message also indicates that the >> normal assocaited output was not generated for >> vm.vmtotal . >>=20 >> I do not know if the error is somehow associated with >> your overlarge swap space (if you still have that). >> In my context "sysctl vm.vmtotal" and "sysctl -a" >> are working normally. >=20 > The 48 is likely related to having excess swap space. > On a machine with 1.77 GB swap the command reports > root@www:/usr/src # sysctl -a | grep -i overcommit > vm.overcommit: 0 It still indicates some invalid internal state in your system. I suggest avoiding being in that status until after your environment no longer has its 2 other problems (hang-ups and jemalloc assertion failures). > I don't think it's related to the assertion failure, > since that host experiences assertion failures as often > as hosts with excess swap space. I recommend avoiding having any reported corruptions active during the search for solutions to your 2 problems: Avoid guessing about interactions of oddities. >>> vm.overcommit: 0 >>=20 >> "man 7 tuning" reports about vm.overcommit : >>=20 >> The vm.overcommit sysctl defines the overcommit behaviour of the = vm >> subsystem. The virtual memory system always does accounting of = the swap >> space reservation, both total for system and per-user. = Corresponding >> values are available through sysctl vm.swap_total, that gives the = total >> bytes available for swapping, and vm.swap_reserved, that gives = number of >> bytes that may be needed to back all currently allocated = anonymous >> memory. >>=20 >> Setting bit 0 of the vm.overcommit sysctl causes the virtual = memory >> system to return failure to the process when allocation of memory = causes >> vm.swap_reserved to exceed vm.swap_total. Bit 1 of the sysctl = enforces >> RLIMIT_SWAP limit (see getrlimit(2)). Root is exempt from this = limit. >> Bit 2 allows to count most of the physical memory as allocatable, = except >> wired and free reserved pages (accounted by = vm.stats.vm.v_free_target and >> vm.stats.vm.v_wire_count sysctls, respectively). >>=20 >>> #=20 >>> It's unclear if this implies yes or no, or even is the correct test. >=20 > I remain uncertain if overcommit is on or off 8-( It seems like = overcommit > limits are intended to keep one user from exhausting swap on a = multiuser > host. Not my situation, if that's the case. =20 It has nothing to do with single-uaer vs. multi-user in general but only in part (i.e, optionally). Also, some of the bit mask values are not really about overcommit but are about somewhat related limitations. More than one of the options can be enabled at the same time but normally none are enabled. A description of overcommit: vm.swap_total < vm.swap_reserved My notes below are in terms of applying a bit mask to pick out a bit and have the result be !=3D 0u (set) vs. =3D=3D 0u (unset). The mask 0x1u being set would lead to rejection of attempts to have: vm.swap_total < vm.swap_reserved You do not have 0x1u set so such rejection is not enabled. The mask 0x2u involves: getrlimit(RLIMIT_SWAP, struct rlimit* cur_and_max) Quoting: RLIMIT_SWAP The maximum size (in bytes) of the swap space that = may be reserved or used by all of this user id's = processes. This limit is enforced only if bit 1 of the = vm.overcommit sysctl is set. Please see tuning(7) for a complete description of this sysctl. So this is a user's-processes-specific limit. You do not have 0x2u set so RLIMIT_SWAP use is not enabled. (Not really overcommit.) The mask 0x4u set might lead to more RAM being considered as allocatable. You do not have 0x4u set so you have normal allocatable physical memory classification in use. (Not really overcommit.) > It can only be said that it's probably whatever is default for = -current. > The sysctl command above was run as root, as is buildworld. The default is always 0x0u: none of the 3 options being enabled. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 14 22:04: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 4d7WPn0Z1tz6GSyw; Fri, 14 Nov 2025 22:04:13 +0000 (UTC) (envelope-from cshapiro@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (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 4d7WPm1W7Dz3Ybg; Fri, 14 Nov 2025 22:04:12 +0000 (UTC) (envelope-from cshapiro@panix.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=FxJwDIYI; dmarc=pass (policy=none) header.from=panix.com; spf=pass (mx1.freebsd.org: domain of cshapiro@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=cshapiro@panix.com Received: from panix3.panix.com (panix3.panix.com [166.84.1.3]) by mailbackend.panix.com (Postfix) with ESMTPS id 4d7WPl2Xrwz49JV; Fri, 14 Nov 2025 17:04:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1763157851; bh=PFyHd4VGumRfkhudOXdpZL1Au86adSjsEaiCTYaGa5I=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=FxJwDIYI0rU/zA4pS+o1hV0cLrHvCkZfuduBuRuqkczGhdSyLjbrK6jM+jfqdVqv5 dWjOwnN3WFxCEMDqpkDdP0dwryKyBj9UCAn0XqigFDx6nBITW9fGY/5vg7AhHHlfSj sAzDbTjmPbht0J5B1vCnNg36aS5pYKJ9yGEsBv+8= From: Carl Shapiro To: bob prohaska Cc: Ronald Klop , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld In-Reply-To: (bob prohaska's message of "Fri, 14 Nov 2025 07:25:27 -0800") References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldkai9lu.fsf@panix.com> <877bvthymv.fsf@panix.com> Date: Fri, 14 Nov 2025 17:04:10 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) 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 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.60 / 15.00]; SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE(1.00)[]; DWL_DNSWL_LOW(-1.00)[panix.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; URIBL_RED(0.50)[zefox.net:email]; BAD_REP_POLICIES(0.10)[]; HAS_ANON_DOMAIN(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[166.84.1.89:from]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[166.84.1.89:from]; DMARC_POLICY_ALLOW(0.00)[panix.com,none]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[panix.com:+]; RCVD_TLS_ALL(0.00)[]; R_DKIM_ALLOW(0.00)[panix.com:s=panix]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:166.84.1.64/26]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4d7WPm1W7Dz3Ybg bob prohaska writes: > Those files have been overwritten by restarting the buildworld sessions. > They tend to be large and diffcult to synchronize with the .cpp and .sh > files generated by the crash. It could be done if it's useful. At least from the perspective of debugging malloc(3), they'd be useful, even if the files for reproducing the crash are not synchronized with the std{err,out} output. For example, there might be other log messages generated by jemalloc. I need a moment to look at the code and step through what it is doing on FreeBSD but my first guess is that there might just be an incorrect assumption about committed memory always coming back zeroed. That should be true on 64-bit Linux when MADV_DONTNEED is used but not true if another advice is used like MADV_FREE on either FreeBSD or Linux. It is always possible that the kernel is mishanding some memory but I would like to rule out jemalloc itself before pointing a finger there. From nobody Sat Nov 15 10:04:08 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 4d7qP06xkgz6HV0J; Sat, 15 Nov 2025 10:04:36 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050:0:465::201]) (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 4d7qP02f2xz3cn0; Sat, 15 Nov 2025 10:04:36 +0000 (UTC) (envelope-from herbert@gojira.at) Authentication-Results: mx1.freebsd.org; none Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (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 mout-p-201.mailbox.org (Postfix) with ESMTPS id 4d7qNk1VtXz9tKc; Sat, 15 Nov 2025 11:04:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gojira.at; s=MBO0001; t=1763201062; 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=kwyvusymLZhv+s4/VpVXuXRa+m64nGvH1DJ2tLX0LTI=; b=ZF7palFeodeleiH1rFWsiQfXtDpnEi9WMbozK8jpSuIhdvoytqhLQNHH2s9ez70U4XofCv mT9cO+w4+E2Y0GuIQTI6znQqfkO81Zq3bWctcfnl8875iuX0V7+DaHVhye8Z2+w1IS3ukf j5fQNvDdAs2jWTd75KeGQLB26HsxmlVH42rBxLnpVoiYcsHnIByYfgvrmc/pfJHKOGHGf6 vCvem+Bmd6A1sCG9+3gSHvd5+J0wMEcEXnaxLgiGmmRlRtw9sB3kN/WCI2/sMoB8XZAVK3 bGqzAnsnj5iMK++8lSi329GyvebfG/0uh4mcro2ENMtyfn2ub1qU5F/J+6NsRA== Date: Sat, 15 Nov 2025 11:04:08 +0100 Message-ID: <87frafr4rr.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: bob prohaska Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld In-Reply-To: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> 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 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:199118, ipnet:2001:67c:2050::/48, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d7qP02f2xz3cn0 On Fri, 14 Nov 2025 16:45:45 +0100, bob prohaska wrote: > > On Fri, Nov 14, 2025 at 08:31:26AM +0100, Herbert J. Skuhra wrote: > > On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska wrote: > > > > > > On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote: > > > > Op 12-11-2025 om 23:25 schreef bob prohaska: > > > > > For lack of any better ideas I've collected some of the assertion failure > > > > > /tmp files by host at > > > > > http://www.zefox.net/~fbsd/assertion_failure/ > > > > > > > > > > Thanks for reading, > > > > > > > > > > bob prohaska > > > > > > > > > > > > > > > > > > A really uneducated guess, but might the update of jemalloc [1] have introduced some subtle issues on armv7? > > > > You can try reverting: https://cgit.freebsd.org/src/commit/?id=c43cad87172039ccf38172129c79755ea79e6102. > > > > > > > What is the required syntax? Trying a simple > > > > > > root@generic:/usr/src # git revert -m 1 c43cad87172039ccf38172129c79755ea79e > > > generated a torrent of conflict reports > > > The source tree is expendable with no valued customizations. > > > > Try: > > > > git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 > > git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 > > git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 > > > > Looks like something fundamental is wrong: > > > root@generic:/usr/src # git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 > contrib/jemalloc/INSTALL.md: unmerged (9701364041c8858d188ba80e629ed33a6ecda67d) > contrib/jemalloc/INSTALL.md: unmerged (90da718d2b6aae8964fdcf35e2ab751fa1b62110) > contrib/jemalloc/INSTALL.md: unmerged (b8f729b0d790f3af09f1519314a69057b08a8384) > contrib/jemalloc/Makefile.in: unmerged (121297702bccc022853e46d46903199b18ac46bc) > contrib/jemalloc/Makefile.in: unmerged (1193cd859c49c027647f2747d77bb8cfe0444d20) > contrib/jemalloc/Makefile.in: unmerged (7128b007ec05359bc88e14615c34e00883ace8b2) > contrib/jemalloc/TUNING.md: unmerged (500541dd52d05f9edf0e690273be190116520d26) > contrib/jemalloc/TUNING.md: unmerged (e96399d7c9b8916297f6530c2b37a7f43ff1651b) > contrib/jemalloc/TUNING.md: unmerged (34fca05b4325035505a6292031c58c8b3f95720f) > contrib/jemalloc/bin/jeprof.in: unmerged (dc2c3ea877b8597b5622976a02c4f5518377aebc) > ... > error: your index file is unmerged. > fatal: revert failed > root@generic:/usr/src # git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 > contrib/jemalloc/INSTALL.md: unmerged (9701364041c8858d188ba80e629ed33a6ecda67d) > contrib/jemalloc/INSTALL.md: unmerged (90da718d2b6aae8964fdcf35e2ab751fa1b62110) > contrib/jemalloc/INSTALL.md: unmerged (b8f729b0d790f3af09f1519314a69057b08a8384) > contrib/jemalloc/Makefile.in: unmerged (121297702bccc022853e46d46903199b18ac46bc) > contrib/jemalloc/Makefile.in: unmerged (1193cd859c49c027647f2747d77bb8cfe0444d20) > contrib/jemalloc/Makefile.in: unmerged (7128b007ec05359bc88e14615c34e00883ace8b2) > contrib/jemalloc/TUNING.md: unmerged (500541dd52d05f9edf0e690273be190116520d26) > contrib/jemalloc/TUNING.md: unmerged (e96399d7c9b8916297f6530c2b37a7f43ff1651b) > contrib/jemalloc/TUNING.md: unmerged (34fca05b4325035505a6292031c58c8b3f95720f) > contrib/jemalloc/bin/jeprof.in: unmerged (dc2c3ea877b8597b5622976a02c4f5518377aebc) > ... > error: your index file is unmerged. > fatal: revert failed > root@generic:/usr/src # git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 > contrib/jemalloc/INSTALL.md: unmerged (9701364041c8858d188ba80e629ed33a6ecda67d) > contrib/jemalloc/INSTALL.md: unmerged (90da718d2b6aae8964fdcf35e2ab751fa1b62110) > contrib/jemalloc/INSTALL.md: unmerged (b8f729b0d790f3af09f1519314a69057b08a8384) > contrib/jemalloc/Makefile.in: unmerged (121297702bccc022853e46d46903199b18ac46bc) > contrib/jemalloc/Makefile.in: unmerged (1193cd859c49c027647f2747d77bb8cfe0444d20) > contrib/jemalloc/Makefile.in: unmerged (7128b007ec05359bc88e14615c34e00883ace8b2) > contrib/jemalloc/TUNING.md: unmerged (500541dd52d05f9edf0e690273be190116520d26) > contrib/jemalloc/TUNING.md: unmerged (e96399d7c9b8916297f6530c2b37a7f43ff1651b) > contrib/jemalloc/TUNING.md: unmerged (34fca05b4325035505a6292031c58c8b3f95720f) > contrib/jemalloc/bin/jeprof.in: unmerged (dc2c3ea877b8597b5622976a02c4f5518377aebc) > ... > error: your index file is unmerged. > fatal: revert failed > root@generic:/usr/src # > > Have I got a corrupted source tree? Or, more likely, did I misunderstand your suggestion? You first have to undo the failed revert: git revert --abort or git reset --hard and then git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 From nobody Sat Nov 15 21:34: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 4d86hK2QJLz6H1Qk; Sat, 15 Nov 2025 21:33:53 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d86hJ656Xz3xHR; Sat, 15 Nov 2025 21:33:52 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AFLYrVK044362 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 15 Nov 2025 13:34:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AFLYqb5044361; Sat, 15 Nov 2025 13:34:52 -0800 (PST) (envelope-from fbsd) Date: Sat, 15 Nov 2025 13:34:52 -0800 From: bob prohaska To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> <87frafr4rr.wl-herbert@gojira.at> 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: <87frafr4rr.wl-herbert@gojira.at> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d86hJ656Xz3xHR On Sat, Nov 15, 2025 at 11:04:08AM +0100, Herbert J. Skuhra wrote: > > You first have to undo the failed revert: > > git revert --abort > or > git reset --hard > > and then > > git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 > git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 > git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 That worked, the machines are now running buildword/kernel. Thank you! bob prohaska From nobody Sat Nov 15 23:08:50 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 4d88pF4cRpz6GPnG for ; Sat, 15 Nov 2025 23:09:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 4d88pD0MW5z47yc for ; Sat, 15 Nov 2025 23:09:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b="q/MTkbU1"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::102a) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-343f35d0f99so2407889a91.0 for ; Sat, 15 Nov 2025 15:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1763248142; x=1763852942; 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=ibmDNSRDFze76TyapGYiLf52sOdDx5RDApeiMoNIV6U=; b=q/MTkbU12WmJLvp+jy1OO8VhtXvCpPJ7OfRrve8UXjLj/EXfMG4xATehyZwn3DHjny X4IGQYA91u5zlz3nAQ4+DsdNYBV4ZypIOC/5OqIt8RGkLgrrVgRVXOMw3ARQZewu9+w4 BnMByOVL53f9GPjQiWdtKdUJSgDlQBl1kH6nFLGQcsO1hQLhhlABtRzAlvrmrHrPCElE M85xOmBlU3i+QUCrrIt39wazx3lgIb+e6Sk9bai16Cj6oIJ/6IpaMghAlqVBrlVRewwG RoP+o3gFQLv6Ub6ArJgmnDVk+wEs/YEiLMrFp3NMPSvNupUv38G4J5DzfmIh5Gs+CgH3 oXQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763248142; x=1763852942; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ibmDNSRDFze76TyapGYiLf52sOdDx5RDApeiMoNIV6U=; b=wT+nYHvv9YjTq4hkmGhNxR+ix9XAM3cVRXIlb9gqNSjCSNlIifgvHbnl3xo6zb6ODh IB14ASi7IqhIhYy+MBscVOQjgKDCi5Lg5JchCeTxHogb5LzEM3loysP4XWAY9FY2zERH neGqgPaN2KgPSarpcAelfWmXMqtu1qwIWaXYa9B8B2s1DYUFUaiMwzTV3PSXVYyY7PaI Ck3rhMT9t5DD1SxeaeQJvVpSShrfP5EivNgwcM7aqNjaBB4e0Z/8OdCSn0rSKU4u+5VD xgV4vwldgoB12lEL4+8Nop3SGxwP466ONi3VX900RQLnJ6/4ffhG1rJM3gzRuRqrdtfz 5uVA== X-Forwarded-Encrypted: i=1; AJvYcCXGCNRjS4paPu/4LxG7MxvslG9hHub8BoMDowybI74UYjCb174vywRqeg7kz6RS3W8Y/iWaC8LMVI8TK3N+k7c=@freebsd.org X-Gm-Message-State: AOJu0YzYv7/IDjsC+MpV45haCcLx6htHG7CgJE4OSKl5JK+2ZbI7+CX9 whPkVkf7k6bB9D3UQTjvFA+adfppsgl9LucZCqVFLCeT6IQ1zBDlik40YLOv2BTMrM9ujuTnoFM zUS5K8Y/7z3u5ZwijO/cPFk8SFYW5NbueMNj4ua2iQg== X-Gm-Gg: ASbGncsJL8CMBULP2q6Miv00aZMN++Wr68vJt+6HxBATUk2jvsJlG5KrEcVZW5q5M53 563WzWLQEDHfoL5nC1JX7o/AqJDLPV6RcR5mBwocqRCrDycehffgu67oC1grRRVxGca5WwTG+lt kJzG5Qqi3Ign7i6Aj/KnEZQDcYVgJ+0WecmNyWeApxKOfqJ/JUFQCotnSGFNZNw2Polu0SV7/G3 dXFZVyRszqQJOv+67/VjIL7PAfSlyw4CTAZjs9zvDzL4TxbmMe2FdcglPFl X-Google-Smtp-Source: AGHT+IGX0aMmt9Fgag8hAicMSMV3HaLoen0AIB2QdhKssSY+53nyf6UVfDN/70SbVSmjXrOBJ99dSYYflgnLAHu9pdI= X-Received: by 2002:a17:90b:3f4f:b0:33b:bed8:891c with SMTP id 98e67ed59e1d1-343fa527eb0mr8688818a91.23.1763248141737; Sat, 15 Nov 2025 15:09:01 -0800 (PST) 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: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> In-Reply-To: <87ldk9f4tt.wl-herbert@gojira.at> From: Warner Losh Date: Sat, 15 Nov 2025 16:08:50 -0700 X-Gm-Features: AWmQ_bkDr3oXhPRxsGC8h9-aXsxxbtp4zltwwFq3PNjO2Ddf_gjvFm0_MMZSmLQ Message-ID: Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000023ae8e0643aa33c0" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102a:from]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[bsdimp.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4d88pD0MW5z47yc --00000000000023ae8e0643aa33c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 14, 2025 at 12:31=E2=80=AFAM Herbert J. Skuhra wrote: > On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska wrote: > > > > On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote: > > > Op 12-11-2025 om 23:25 schreef bob prohaska: > > > > For lack of any better ideas I've collected some of the assertion > failure > > > > /tmp files by host at > > > > http://www.zefox.net/~fbsd/assertion_failure/ > > > > > > > > Thanks for reading, > > > > > > > > bob prohaska > > > > > > > > > > > > > > A really uneducated guess, but might the update of jemalloc [1] have > introduced some subtle issues on armv7? > > > You can try reverting: > https://cgit.freebsd.org/src/commit/?id=3Dc43cad87172039ccf38172129c79755= ea79e6102 > . > > > > > What is the required syntax? Trying a simple > > > > root@generic:/usr/src # git revert -m 1 > c43cad87172039ccf38172129c79755ea79e > > generated a torrent of conflict reports > > The source tree is expendable with no valued customizations. > > Try: > > git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 > git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 > git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 > Do you have to do all three? I'd have thought only the first one would be needed. Warner --00000000000023ae8e0643aa33c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 14,= 2025 at 12:31=E2=80=AFAM Herbert J. Skuhra <herbert@gojira.at> wrote:
On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska= wrote:
>
> On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote:
> > Op 12-11-2025 om 23:25 schreef bob prohaska:
> > > For lack of any better ideas I've collected some of the = assertion failure
> > > /tmp files by host at
> > > http://www.zefox.net/~fbsd/assertion_fai= lure/
> > >
> > > Thanks for reading,
> > >
> > > bob prohaska
> > >
> > >
> >
> > A really uneducated guess, but might the update of jemalloc [1] h= ave introduced some subtle issues on armv7?
> > You can try reverting: https://cgit.freebsd.org/src/commit/?id=3Dc43cad87172039ccf3= 8172129c79755ea79e6102.
> >
> What is the required syntax? Trying a simple
>
> root@generic:/usr/src # git revert -m 1 c43cad87172039ccf38172129c7975= 5ea79e
> generated a torrent of conflict reports
> The source tree is expendable with no valued customizations.

Try:

git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8
git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353
git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102

Do you have to do all three? I'd have thought only= the first one would be needed.

Warner=C2=A0
=
--00000000000023ae8e0643aa33c0-- From nobody Sun Nov 16 09:29:00 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 4d8QYk5bkPz6HLx0 for ; Sun, 16 Nov 2025 09:29:14 +0000 (UTC) (envelope-from tschweikle@gmail.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 4d8QYj2XPMz4PVH for ; Sun, 16 Nov 2025 09:29:13 +0000 (UTC) (envelope-from tschweikle@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=UERRD2gB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of tschweikle@gmail.com designates 2607:f8b0:4864:20::835 as permitted sender) smtp.mailfrom=tschweikle@gmail.com Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-4eda6c385c0so28069901cf.3 for ; Sun, 16 Nov 2025 01:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763285352; x=1763890152; 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=ACZmGClVkhVe9Y6nznc4MrEJ5CL55oP2t+zzfZah8lA=; b=UERRD2gByeMxJVJs4YyC9belJObIT7Ww7znn/6yy6QyOwvJcwZ03JQSNjr3dwnHj81 wx447GOSsyxtEM0LTm+sNRp5Cf7Q4dqUQiIOD5yIoKO29K1V/LUHen8WiNSLnX3TyqzY gRPORGgpoeNd79Kl40QgAve583rfLjWchEwEcHkxu9t8XxfV5ugmpt1S5Xqzd0dYrnHP zUsi7dZnfMAQdgJvRPSA3g7s0pnYxBrRMHFc1nNDPgaxoJ1JoCpLYhQGn7C3h0tdQPBZ eJzFxrEmaRZ5HZqv9a/6uzfG/nRcCg2SXZYiiTM8h9bT2jbGpejUjuJ17BfXostDYTUV 7eDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763285352; x=1763890152; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ACZmGClVkhVe9Y6nznc4MrEJ5CL55oP2t+zzfZah8lA=; b=Y8bE/vbirNilIBlAznCmzZ31dSppRdkWeJL9NjjfzAcoCjsRlOeCM3y7eF7YLGA5jf Wkj8ViQ/afRz0ZE93UdcbxJ7ZW7jK3PM3kSv0eXwRLbyeezX8dNtvGPw4b4SwMg4guOb n7vZh7xyaN+RI3aE/nenkOYLnNN3E8TMH6nWFZ4wVJ1VT0OoVk2tPXFSWbNCUJ9sHMEu 9KIbXPUNxEQBqQxQ8sKxdMMnGZwBITV1ueDO20c2aje3+nx/gWvSixb9uxVndUHKTyWV DlyLbV7tmKoifv6Z+7PZkB5YkpIR2O9P238n9Pwy28d6izWE2oMxVdYNwUJCgoh1iCll RQYw== X-Gm-Message-State: AOJu0YzZ8AucnbgQcZhGS1Ks7TF1KHP42wWVinnavQXuPHALir0JgWPf NUBGbXeNQQFEkfcWpLI4Z6yf8WQmI+NYgiWM5N1Vu52xsh32YyvDgHspMx7YUSBQsfOqyKwD3cz gxuhndt42VTtIoEvon2bFZtIcdH4au8qWOQ== X-Gm-Gg: ASbGncvS7SHUFUa0xaOBaf7GQB09MfkJ8D+Y7eONntar5fvC1ItYSM3ATOtCF/uR95t e8mk2Qa6fq2j9+9SBR2zXkmWECVF+lGVKHfeu/JdV5DAtM+dF8q2xWR8VbZkhJK94yCWpRC3o/n /YXKSxhfE9bsUeMGwifoT69IPw8yt/epNA1ZTIdjycVCwSGrRtPGy/RKfuI9Ds9hp9CVPWZpCkF mHEj8thhMfu3eO/oL3lG/9GDq4SH1WCj1nSxnVQO2Ph8Llj1BE/qNHaDWiuot7KKncDVqtIUjNJ LBIzPcPQ0Bv26fHrU1kFFYwfj+ae X-Google-Smtp-Source: AGHT+IFfsI69yApYBpymcRBGBxaP/CbmRzHzqNLJPV1S7I81ApGfo/45q+ib4qDJFdK56Z7qMu9LPZyWA7pZo2m1RYE= X-Received: by 2002:a05:622a:14d4:b0:4ec:f29f:d95d with SMTP id d75a77b69052e-4edf210f4camr115782671cf.58.1763285351693; Sun, 16 Nov 2025 01:29:11 -0800 (PST) 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: <86qzuo1ab1.fsf@ltc.des.dev> <868qgw14xj.fsf@ltc.des.dev> <864irj1ett.fsf@ltc.des.dev> <86jz0fyzjj.fsf@ltc.des.dev> <31a80d2d-65b3-4604-ac5f-1440d23fb85a@plan-b.pwste.edu.pl> <43c4ae93-71e2-4b2e-b265-b84b96a70666@plan-b.pwste.edu.pl> <4570E827-C9ED-4473-AE60-C895DBD9C2BF@ketas.si.pri.ee> <2121B7E6-0DB6-427A-9C72-640A3AEE26AA@ketas.si.pri.ee> In-Reply-To: From: Thomas Schweikle Date: Sun, 16 Nov 2025 10:29:00 +0100 X-Gm-Features: AWmQ_bnzuwM6N034E0hYJvuoFNhe8GA7pi1tnRur8gHL99ixC5l5V6PULrdhTRo Message-ID: Subject: Re: "etcupdate extract" -- Failed to build new tree. To: Sulev-Madis Silber Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000000683510643b2ddc1" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.71 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; NEURAL_HAM_SHORT(-0.75)[-0.749]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::835:from] X-Rspamd-Queue-Id: 4d8QYj2XPMz4PVH --0000000000000683510643b2ddc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Seems like someone "optimized" "./mk_cmds" by changing permissions to "chmod 0755 m/mk_cmds*", then directly calling "./mk_cmds". Within older versions of "etcupdate" it was executed by "/bin/sh ./mk_cmds". "/bin/sh ./mk_cmds" circumvents "noexec". But it makes it possible to compile sources without executing anything within /usr/src directly. But: while /usr/src is mounted zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) /usr/obj is mounted zroot/usr on /usr (zfs, local, nfsv4acls) And both mounts are what FreeBSD on zfs with GPT ( https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot) expects (copied right from the handbook pages): zfs create -o mountpoint=3D/tmp -o exec=3Don -o setuid=3Doff zroot/= tmp zfs create -o canmount=3Doff -o mountpoint=3D/usr zroot/us= r zfs create zroot/usr/ho= me zfs create -o exec=3Doff -o setuid=3Doff zroot/us= r/src zfs create zroot/usr/ob= j zfs create -o mountpoint=3D/usr/ports -o setuid=3Doff zroot/us= r/ports zfs create -o exec=3Doff -o setuid=3Doff zroot/usr/ports/distfiles zfs create -o exec=3Doff -o setuid=3Doff zroot/usr/ports/packages zfs create -o canmount=3Doff -o mountpoint=3D/var zroot/va= r zfs create -o exec=3Doff -o setuid=3Doff zroot/va= r/audit zfs create -o exec=3Doff -o setuid=3Doff zroot/va= r/crash zfs create -o exec=3Doff -o setuid=3Doff zroot/va= r/log zfs create -o atime=3Don -o exec=3Doff -o setuid=3Doff zroot/= var/mail zfs create -o exec=3Don -o setuid=3Doff zroot/va= r/tmp Since "etcupdate" worked about four months ago, then it started to stop working, something has changed with how it works. For me it looks like there creating mk_cmds within /usr/src, instead within /usr/obj. This was ok as long as mk_cmds was called with "/bin/sh ./mk_cmds". As soon as this was changed to "chmod 0755 mk_cmds*; ./mk_cmds" it broke. I've tested a lot last days. It is not "noexec" set for "/usr/src". It is something changed just before forking "stable/15". Going back to this makes it working again (as it does copying "etcupdate" from "stable/14". On Sun, Nov 9, 2025 at 2:49=E2=80=AFAM Sulev-Madis Silber < freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote: > > > On November 8, 2025 10:36:43 PM GMT+02:00, Thomas Schweikle < > tschweikle@gmail.com> wrote: > >On Sat, Nov 8, 2025 at 8:00=E2=80=AFPM Sulev-Madis Silber < > >freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote: > > > >> first thing that comes to my mind... > >> > >> is there any other fs where noexec is used? > >> > >The other systems are set up the same way, mounting /usr/src > >zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) > > > > > >> especially on which the etcupdate actually runs on? > >> > >It runs on three other systems: > >- stable/13 > >- stable/14 > >and a pre stable/15 (before ALPHA was out and the branch done). > > > >It does not run if executed on a > >- stable/15 > >- current > > > >in both cases "make buildetc" works as expected if not called from insid= e > >"etcupdate". > > > > > >> i haven't so far studied the whole thing but if you have put noexec > >> everywhere, including tmp dirs or whatever etcupdate uses, it could be > it! > >> > >noexec does not touch "root", but standard users. Does etcupdate switch = to > >some other user while executing? Does it do so before branching stable/1= 5? > > unfortunately noexec don't even let root execute anything directly > > read works, shell scripts, makefiles > > if you have other fses in that very same machine mounted noexec then this > code will fail. and it indeed does give permission denied > > i don't know where mk_cmds is. perhaps in obj? i'm currently not debuggin= g > this > > whether it should be able to run noexec, no idea, not everything can be > > noexec is there by purpose i assume, but maybe it could be temporary > disabled > > btw noexec as a security measure can be also bypassed > > tell us if disabling noexec on fses helped > > that's also fun thing, that not many add, or if they do, they know what > happens. many building type tasks like to execute something in dirs > > you didn't tell that you had noexec on and nobody asked either so maybe > it's noexec for all that time and you had to do manual work > > i hope it's fixed now!!! > > > > >And just switching into /usr/src, then executing "make etcupdate" does > call > >"./mk_cmds" and it does not fail because it is forbidden to run -- it > runs. > > > >just a wild guess. noexec is not always used and it often blows up rando= m > >> thing unexpectedly. others have it disabled and therefore don't see it > >> > >> > >> > >> On November 8, 2025 8:21:22 PM GMT+02:00, Thomas Schweikle < > >> tschweikle@gmail.com> wrote: > >> >Looking at the log from etcupdate I found it failing with > >> > > >> >chmod 755 mk_cmds > >> >rm -f et-h-ss_err.et et-h-ss_err.c et-h-ss_err.h > >> >cp /usr/src/crypto/krb5/src/util/ss/ss_err.et et-h-ss_err.et > >> >compile_et -d /usr/src/crypto/krb5/src/util/et --textdomain mit-krb5 > >> >et-h-ss_err.et > >> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h.awk > >> >'outfile=3Det-h-ss_err.h' et-h-ss_err.et > >> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c.awk > >> >'outfile=3Det-h-ss_err.c' 'textdomain=3Dmit-krb5' 'localedir=3D' > et-h-ss_err.et > >> >mv et-h-ss_err.h ss_err.h > >> >rm -f et-h-ss_err.et et-h-ss_err.h > >> >./mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs.ct > >> >make[4]: exec(./mk_cmds): Permission denied > >> >*** Error code 1 > >> > > >> >Stop. > >> >make[4]: stopped making "all" in /usr/src/krb5/util/ss > >> >*** Error code 1 > >> > > >> >Stop. > >> >make[3]: stopped making "bootstrap-tools" in /usr/src > >> > 10.16 real 8.75 user 1.04 sys > >> >*** Error code 1 > >> > > >> >Stop. > >> >make[2]: stopped making "_bootstrap-tools" in /usr/src > >> >*** Error code 1 > >> > > >> >Stop. > >> >make[1]: stopped making "buildetc" in /usr/src > >> >*** Error code 1 > >> > > >> >Stop. > >> >make: stopped making "buildetc" in /usr/src > >> > > >> >It fails, because it is not allowed to "exec ./mk_cmds", after settin= g > >> >"chmod 0755" for "mk_cmds"? Within "/usr/src" "mk_cmds" just does not > >> exist > >> >=E2=80=93 as long as "find /usr/src -iname '*mk_cmds*' -print" would = be able to > >> >find it: > >> >/usr/src # find . -iname '*/mk_cmds/*' > >> >/usr/src # > >> > > >> >"/usr/src" is mounted > >> >zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls) > >> > > >> >AND what makes it even more mysterious: > >> ># cd /usr/src > >> ># make buildetc > >> > > >> >works without reporting any error. If called from "etcupdate extract" > it > >> >fails. > >> > > >> >It works for FreeBSD: > >> >- stable/13 > >> >- stable/14 > >> > > >> >but not for: > >> >- stable/15 > >> > > >> >Full log is attached. > >> > > >> >On Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber < > >> >freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote: > >> > > >> >> something bad clearly happened in that machine if it's able to > selfhost > >> >> build itself and work, except etcupdate. and that for a long time > >> >> > >> >> i don't see any reason getting pissed about his machine mysteriousl= y > not > >> >> working, despite i haven't broken any machine myself since i > installed > >> >> first fbsd, 4.6 > >> >> > >> >> unsure how to go from here. unsure if src.conf or make.conf matters > here > >> >> > >> >> if this happens in currently actively supported fbsd release, maybe > >> >> etcupdate needs a bugfix to cleanup for edge cases > >> >> > >> >> if it's in unsupported, that should not cause any "pissages" either= . > fix > >> >> is somewhere > >> >> > >> >> so, the admin updated files manually because he was not able to get > it > >> >> working? i bet you can recreate it and fix it for future cases > >> >> > >> >> since i haven't ever broken etcupdate, i don't know which data it > uses > >> as > >> >> input. but seems like it reads wrong data out of somewhere. and > entire > >> >> machine works, except this? > >> >> > >> >> i mean if this was bad upgrade leftover, how to fix? i mean doesn't > >> >> etcupdate get rework now, for pkgbase. while we do that, maybe it > could > >> be > >> >> made to handle this. or maybe even given non-destructive nuke mode = so > >> >> people can start clean > >> >> > >> >> i don't think it's really entirely user error, considering he didn'= t > >> break > >> >> the machine > >> >> > >> >> i'm curious too. at worst you could do other install in another > machine > >> >> and compare dirs as something must differ there. then, according to > >> >> findings, fix the old machine. maybe while doing this, some new > bugfix > >> idea > >> >> appears > >> >> > >> >> but hell with getting mad over machine. he's pissed too, everyone's > >> >> pissed, server is not working and no productive work have been done > here > >> >> > >> >> maybe something got lost in translation too > >> >> > >> >> > >> > > >> > >> > > > > --=20 Thomas --0000000000000683510643b2ddc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Seems like someone "optimized" "./mk_cmds&q= uot; by changing permissions to "chmod 0755 m/mk_cmds*", then dir= ectly calling "./mk_cmds". Within older versions of "etcupda= te" it was executed by "/bin/sh ./mk_cmds". "/bin/sh ./= mk_cmds" circumvents "noexec". But it makes it possible to c= ompile sources=C2=A0without executing anything within /usr/src directly.
But: while /usr/src is mounted
zro= ot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls)
=

/usr/obj is mounted
zroot/usr on /usr (zfs, local, nfsv4acls)
<= br>
And both mounts are what FreeBSD on zfs with GPT (https://wi= ki.freebsd.org/RootOnZFS/GPTZFSBoot) expects (copied right from the han= dbook pages):
zfs create -o mountpoint=3D/tmp  -o exec=3Do=
n      -o setuid=3Doff   zroot/tmp
zfs create -o canmount=3Doff -o mountpoint=3D/usr                  zroot/us=
r
zfs create                                                     zroot/usr/ho=
me
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/us=
r/src
zfs create                                                     zroot/usr/ob=
j
zfs create -o mountpoint=3D/usr/ports            -o setuid=3Doff   zroot/us=
r/ports
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/us=
r/ports/distfiles
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/us=
r/ports/packages
zfs create -o canmount=3Doff -o mountpoint=3D/var                  zroot/va=
r
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/va=
r/audit
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/va=
r/crash
zfs create                     -o exec=3Doff     -o setuid=3Doff   zroot/va=
r/log
zfs create -o atime=3Don         -o exec=3Doff     -o setuid=3Doff   zroot/=
var/mail
zfs create                     -o exec=3Don      -o setuid=3Doff   zroot/va=
r/tmp

Since "etcupdate" worked abo= ut four months ago, then it started to stop working, something has changed = with how it works. For me it looks like there creating mk_cmds within /usr/= src, instead within /usr/obj. This was ok as long as mk_cmds was called wit= h "/bin/sh ./mk_cmds". As soon as this was changed to "chmod= 0755 mk_cmds*; ./mk_cmds" it broke.

I've= tested a lot last days. It is not "noexec" set for "/usr/sr= c". It is something changed just before forking "stable/15".= Going back to this makes it working again (as it does copying "etcupd= ate" from "stable/14".

On Sun, Nov 9, 2025 at 2:49=E2= =80=AFAM Sulev-Madis Silber <freebsd-current-freebsd-org111@ket= as.si.pri.ee> wrote:


On November 8, 2025 10:36:43 PM GMT+02:00, Thomas Schweikle <tschweikle@gmail.com>= wrote:
>On Sat, Nov 8, 2025 at 8:00=E2=80=AFPM Sulev-Madis Silber <
>freebsd-current-freebsd-org111@ketas.si.pri.ee> wrote:<= br> >
>> first thing that comes to my mind...
>>
>> is there any other fs where noexec is used?
>>
>The other systems are set up the same way, mounting /usr/src
>zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4acls)
>
>
>> especially on which the etcupdate actually runs on?
>>
>It runs on three other systems:
>- stable/13
>- stable/14
>and a pre stable/15 (before ALPHA was out and the branch done).
>
>It does not run if executed on a
>- stable/15
>- current
>
>in both cases "make buildetc" works as expected if not called= from inside
>"etcupdate".
>
>
>> i haven't so far studied the whole thing but if you have put n= oexec
>> everywhere, including tmp dirs or whatever etcupdate uses, it coul= d be it!
>>
>noexec does not touch "root", but standard users. Does etcupd= ate switch to
>some other user while executing? Does it do so before branching stable/= 15?

unfortunately noexec don't even let root execute anything directly

read works, shell scripts, makefiles

if you have other fses in that very same machine mounted noexec then this c= ode will fail. and it indeed does give permission denied

i don't know where mk_cmds is. perhaps in obj? i'm currently not de= bugging this

whether it should be able to run noexec, no idea, not everything can be

noexec is there by purpose i assume, but maybe it could be temporary disabl= ed

btw noexec as a security measure can be also bypassed

tell us if disabling noexec on fses helped

that's also fun thing, that not many add, or if they do, they know what= happens. many building type tasks like to execute something in dirs

you didn't tell that you had noexec on and nobody asked either so maybe= it's noexec for all that time and you had to do manual work

i hope it's fixed now!!!

>
>And just switching into /usr/src, then executing "make etcupdate&q= uot; does call
>"./mk_cmds" and it does not fail because it is forbidden to r= un -- it runs.
>
>just a wild guess. noexec is not always used and it often blows up rand= om
>> thing unexpectedly. others have it disabled and therefore don'= t see it
>>
>>
>>
>> On November 8, 2025 8:21:22 PM GMT+02:00, Thomas Schweikle < >> tschweik= le@gmail.com> wrote:
>> >Looking at the log from etcupdate I found it failing with
>> >
>> >chmod 755 mk_cmds
>> >rm -f et-h-ss_err.et et-h-ss_err.c et-h-ss_err.h
>> >cp /usr/src/crypto/krb5/src/util/ss/ss_err.et et-h-ss_err.et
>> >compile_et -d /usr/src/crypto/krb5/src/util/et --textdomain mi= t-krb5
>> >et-h-ss_err.et
>> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_h.awk >> >'outfile=3Det-h-ss_err.h' et-h-ss_err.et
>> >+ /usr/bin/awk -f /usr/src/crypto/krb5/src/util/et/et_c.awk >> >'outfile=3Det-h-ss_err.c' 'textdomain=3Dmit-krb5&#= 39; 'localedir=3D' et-h-ss_err.et
>> >mv et-h-ss_err.h ss_err.h
>> >rm -f et-h-ss_err.et et-h-ss_err.h
>> >./mk_cmds /usr/src/crypto/krb5/src/util/ss/std_rqs.ct
>> >make[4]: exec(./mk_cmds): Permission denied
>> >*** Error code 1
>> >
>> >Stop.
>> >make[4]: stopped making "all" in /usr/src/krb5/util/= ss
>> >*** Error code 1
>> >
>> >Stop.
>> >make[3]: stopped making "bootstrap-tools" in /usr/sr= c
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A010.16 real=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A08.75 user=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.04 sys
>> >*** Error code 1
>> >
>> >Stop.
>> >make[2]: stopped making "_bootstrap-tools" in /usr/s= rc
>> >*** Error code 1
>> >
>> >Stop.
>> >make[1]: stopped making "buildetc" in /usr/src
>> >*** Error code 1
>> >
>> >Stop.
>> >make: stopped making "buildetc" in /usr/src
>> >
>> >It fails, because it is not allowed to "exec ./mk_cmds&qu= ot;, after setting
>> >"chmod 0755" for "mk_cmds"? Within "/= usr/src" "mk_cmds" just does not
>> exist
>> >=E2=80=93 as long as "find /usr/src -iname '*mk_cmds*= ' -print" would be able to
>> >find it:
>> >/usr/src # find . -iname '*/mk_cmds/*'
>> >/usr/src #
>> >
>> >"/usr/src" is mounted
>> >zroot/usr/src on /usr/src (zfs, local, noexec, nosuid, nfsv4ac= ls)
>> >
>> >AND what makes it even more mysterious:
>> ># cd /usr/src
>> ># make buildetc
>> >
>> >works without reporting any error. If called from "etcupd= ate extract" it
>> >fails.
>> >
>> >It works for FreeBSD:
>> >- stable/13
>> >- stable/14
>> >
>> >but not for:
>> >- stable/15
>> >
>> >Full log is attached.
>> >
>> >On Tue, Nov 4, 2025 at 4:00=E2=80=AFPM Sulev-Madis Silber <=
>> >freebsd-current-freebsd-org111@ketas.si.pri.ee>= ; wrote:
>> >
>> >> something bad clearly happened in that machine if it'= s able to selfhost
>> >> build itself and work, except etcupdate. and that for a l= ong time
>> >>
>> >> i don't see any reason getting pissed about his machi= ne mysteriously not
>> >> working, despite i haven't broken any machine myself = since i installed
>> >> first fbsd, 4.6
>> >>
>> >> unsure how to go from here. unsure if src.conf or make.co= nf matters here
>> >>
>> >> if this happens in currently actively supported fbsd rele= ase, maybe
>> >> etcupdate needs a bugfix to cleanup for edge cases
>> >>
>> >> if it's in unsupported, that should not cause any &qu= ot;pissages" either. fix
>> >> is somewhere
>> >>
>> >> so, the admin updated files manually because he was not a= ble to get it
>> >> working? i bet you can recreate it and fix it for future = cases
>> >>
>> >> since i haven't ever broken etcupdate, i don't kn= ow which data it uses
>> as
>> >> input. but seems like it reads wrong data out of somewher= e. and entire
>> >> machine works, except this?
>> >>
>> >> i mean if this was bad upgrade leftover, how to fix? i me= an doesn't
>> >> etcupdate get rework now, for pkgbase. while we do that, = maybe it could
>> be
>> >> made to handle this. or maybe even given non-destructive = nuke mode so
>> >> people can start clean
>> >>
>> >> i don't think it's really entirely user error, co= nsidering he didn't
>> break
>> >> the machine
>> >>
>> >> i'm curious too. at worst you could do other install = in another machine
>> >> and compare dirs as something must differ there. then, ac= cording to
>> >> findings, fix the old machine. maybe while doing this, so= me new bugfix
>> idea
>> >> appears
>> >>
>> >> but hell with getting mad over machine. he's pissed t= oo, everyone's
>> >> pissed, server is not working and no productive work have= been done here
>> >>
>> >> maybe something got lost in translation too
>> >>
>> >>
>> >
>>
>>
>



--
Thomas
--0000000000000683510643b2ddc1-- From nobody Sun Nov 16 15:43:54 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 4d8Zrn0KL1z6Gcn1; Sun, 16 Nov 2025 15:42:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d8Zrm2hHWz3flq; Sun, 16 Nov 2025 15:42:48 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AGFhtcb048339 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 16 Nov 2025 07:43:55 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AGFhsmo048338; Sun, 16 Nov 2025 07:43:54 -0800 (PST) (envelope-from fbsd) Date: Sun, 16 Nov 2025 07:43:54 -0800 From: bob prohaska To: Warner Losh Cc: "Herbert J. Skuhra" , freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld Message-ID: References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d8Zrm2hHWz3flq On Sat, Nov 15, 2025 at 04:08:50PM -0700, Warner Losh wrote: > On Fri, Nov 14, 2025 at 12:31 AM Herbert J. Skuhra > wrote: > > > On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska wrote: > > > > > > On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote: > > > > Op 12-11-2025 om 23:25 schreef bob prohaska: > > > > > For lack of any better ideas I've collected some of the assertion > > failure > > > > > /tmp files by host at > > > > > http://www.zefox.net/~fbsd/assertion_failure/ > > > > > > > > > > Thanks for reading, > > > > > > > > > > bob prohaska > > > > > > > > > > > > > > > > > > A really uneducated guess, but might the update of jemalloc [1] have > > introduced some subtle issues on armv7? > > > > You can try reverting: > > https://cgit.freebsd.org/src/commit/?id=c43cad87172039ccf38172129c79755ea79e6102 > > . > > > > > > > What is the required syntax? Trying a simple > > > > > > root@generic:/usr/src # git revert -m 1 > > c43cad87172039ccf38172129c79755ea79e > > > generated a torrent of conflict reports > > > The source tree is expendable with no valued customizations. > > > > Try: > > > > git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 > > git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 > > git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 > > > > Do you have to do all three? I'd have thought only the first one would be > needed. Necessary or not, it seems to have worked. No errors were reported and buildworld/kernel has run successfully on two of three Pi2's. One of them has rebooted and run an incremental buildworld using its new kernel and world. Next step is to run make cleandir twice on that machine and try a clean-start buildworld/kernel. Those results will take a few days. In the meantime, is there any explicit test to see if the reversion worked as expected? Searching for null (no error) results is slow. For example, Peter Holm's stress2 suite found lots of mischief in years gone by, might it be applied to this sort of problem? Thanks to you and everybody else for your help! bob prohaska From nobody Sun Nov 16 17:51: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 4d8dj44D7sz6Gpw5 for ; Sun, 16 Nov 2025 17:51:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 4d8dj36DJdz3v69 for ; Sun, 16 Nov 2025 17:51:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-343684a06b2so3114265a91.1 for ; Sun, 16 Nov 2025 09:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1763315473; x=1763920273; 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=T7JYXy+RBg4lEmb5zG0L1qqSL3AEzof1js0rO4fVvr0=; b=C3MM0Sc1HHNgebGbi11m5GddHjIzs6NcS7Rty2Q8izPQ5Xh2LHGhjefJ79x7DewmV6 Rq+9x4gIt49LhGMeBdkRh+TqWL9qK+wMrCXQeW/dtdSUK4B4X2QoyAH/JNBCyZoZc+6R c57sqKdXeIKjWDZCdNLRHqLiz+I8wRweugf8JxoyjnJWNQqvCAKLs4bSSvpfCdNEnGil puM5KG77Wgg3+pge1mtJ2ott/KuzWWXwF1eygnNjdx0LtM0V2lkD7zfI0VGwhuMCuNpC QMUQQvGR09Ro94LArQ5X2LyexnLV2F/70g28vwb2O5w0VOGGEj69eoMYL5PBqEz13B9e Z9cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763315473; x=1763920273; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=T7JYXy+RBg4lEmb5zG0L1qqSL3AEzof1js0rO4fVvr0=; b=g8YxZM8KJROqHoMph+wJJ6lQfI4QeYdYSta+jq6cyAc0sN2k5QRisjrXdNljp8pRlp 6T03fI9YKlyIzRrYyHSHfHg9VXJvMd3LUh2BnL9btLA0dMiA6Gw0zDDNKWV2MBnDQVcj F6eil3AQ5wI5qmOPLp4iEtm4JbYt0i5NAGxTysEnNr6J21pz05HOXhcGIJbS9iET5hnh t9pXfOOHPD89tZu7ibiZOVxTBSKDxP4s/S7PUbzjfFs8uO4hF4kaC5P0NUS5TBEF/tmB gpoTrTYDnc3D79xBdPYW7mukhXEIbLEkDJ7amZlOMGz9x1x1jxLVrRmPSQm3yf7l0HR6 +cBg== X-Forwarded-Encrypted: i=1; AJvYcCVVWma2HzfdVDOUhX+aQFMMpc18klY64jX2UvVNBokt8mmLsBlOJQD/j3sxGJRBXbN0VavN3qXQKCSzwOupjHE=@freebsd.org X-Gm-Message-State: AOJu0YzijRR9gJyM0GgMFYhsSkHT4++xbFaUqcX9ADmOC8wLWx91qLd+ pmY/gxQj0vXKJookIYENnfU2J8vj1oX0p43kCLfQd6xKHBbB6eItmI7yOukHltx6YDSTlAeWCIw C6kT4yg9bqDYGElAai7LqgV4LwtJ//2dOZbztsox/NQ== X-Gm-Gg: ASbGncualoXczk/gaGyyXmxByvVVQ+FO23JJD7i85+9Hs6QerYqmACEudIopya3bqMj uTmIwMRkIKbks1drgtRO4rg+WP2Vh4u8Xd5dYOdJNTVwX61t4vUrNXI15Hn3SKfodYlIK9Gq0Tl h6UyoczuxhYeH7Fpisxb96ZJafsBAtaUjttL6yuJTS31IdZX1Nq0iBIMXfCfN+4U/t5cYNuyw6S 3dP4EUJa26OUWFwSa5XaWzQRVzuTFYZtNaECMdXLTP6XpLYn39TOTra3yH2E1ONqrWxi4U= X-Google-Smtp-Source: AGHT+IEFc3Z1kK9Yef1ns68w80tv0nL5flpDN/+gY5qTy8A82FyR4rMmbDqfATsZrVkbU8NBZS+UkEoQeC3S1hweTZ0= X-Received: by 2002:a17:90b:5544:b0:340:99fd:9676 with SMTP id 98e67ed59e1d1-343f9eaf809mr9530543a91.10.1763315472978; Sun, 16 Nov 2025 09:51:12 -0800 (PST) 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: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> In-Reply-To: From: Warner Losh Date: Sun, 16 Nov 2025 10:51:01 -0700 X-Gm-Features: AWmQ_bn7aVurLZjYow5OkxhG0K-YNzqo1Dq3aznur4jywbtnkIcql6_EbIpWfdY Message-ID: Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld To: bob prohaska Cc: "Herbert J. Skuhra" , "freebsd-arm@freebsd.org" , FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000064e2d50643b9e032" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d8dj36DJdz3v69 --00000000000064e2d50643b9e032 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maybe try main with the following patch. Adrian noticed the TLS mismatch. I don't think it will matter, but TLS thread model stuff always gives me a big headache. If the following fails to apply, just copy the JEMALLOC_TLS_MODEL line from i386 to arm. The default changed elsewhere, but this wasn't updated here. Warner diff --git a/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h index 34c86271ab2e..bd6850ebd95f 100644 --- a/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h +++ b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h @@ -26,10 +26,11 @@ #undef LG_SIZEOF_LONG #undef LG_SIZEOF_INTMAX_T +#define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) + #ifdef __i386__ # define LG_VADDR 32 # define LG_SIZEOF_PTR 2 -# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) #endif #ifdef __ia64__ # define LG_VADDR 64 @@ -38,7 +39,6 @@ #ifdef __sparc64__ # define LG_VADDR 64 # define LG_SIZEOF_PTR 3 -# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) #endif #ifdef __amd64__ #ifdef _USE_LG_VADDR_WIDE @@ -47,7 +47,6 @@ # define LG_VADDR 48 #endif # define LG_SIZEOF_PTR 3 -# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) #endif #ifdef __arm__ # define LG_VADDR 32 @@ -69,11 +68,9 @@ #ifdef __powerpc64__ # define LG_VADDR 64 # define LG_SIZEOF_PTR 3 -# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) #elif defined(__powerpc__) # define LG_VADDR 32 # define LG_SIZEOF_PTR 2 -# define JEMALLOC_TLS_MODEL __attribute__((tls_model("initial-exec"))) #endif #ifdef __riscv # define LG_VADDR 48 On Sun, Nov 16, 2025, 8:42=E2=80=AFAM bob prohaska wro= te: > On Sat, Nov 15, 2025 at 04:08:50PM -0700, Warner Losh wrote: > > On Fri, Nov 14, 2025 at 12:31=E2=80=AFAM Herbert J. Skuhra > > wrote: > > > > > On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska wrote: > > > > > > > > On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote: > > > > > Op 12-11-2025 om 23:25 schreef bob prohaska: > > > > > > For lack of any better ideas I've collected some of the asserti= on > > > failure > > > > > > /tmp files by host at > > > > > > http://www.zefox.net/~fbsd/assertion_failure/ > > > > > > > > > > > > Thanks for reading, > > > > > > > > > > > > bob prohaska > > > > > > > > > > > > > > > > > > > > > > A really uneducated guess, but might the update of jemalloc [1] > have > > > introduced some subtle issues on armv7? > > > > > You can try reverting: > > > > https://cgit.freebsd.org/src/commit/?id=3Dc43cad87172039ccf38172129c79755= ea79e6102 > > > . > > > > > > > > > What is the required syntax? Trying a simple > > > > > > > > root@generic:/usr/src # git revert -m 1 > > > c43cad87172039ccf38172129c79755ea79e > > > > generated a torrent of conflict reports > > > > The source tree is expendable with no valued customizations. > > > > > > Try: > > > > > > git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 > > > git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 > > > git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 > > > > > > > Do you have to do all three? I'd have thought only the first one would = be > > needed. > > Necessary or not, it seems to have worked. No errors were reported and > buildworld/kernel has run successfully on two of three Pi2's. One of > them has rebooted and run an incremental buildworld using its new kernel > and world. > > Next step is to run make cleandir twice on that machine and try a > clean-start buildworld/kernel. Those results will take a few days. > > In the meantime, is there any explicit test to see if the reversion > worked as expected? Searching for null (no error) results is slow. > > For example, Peter Holm's stress2 suite found lots of mischief in > years gone by, might it be applied to this sort of problem? > > Thanks to you and everybody else for your help! > > bob prohaska > > --00000000000064e2d50643b9e032 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe try main with the following patch. Adrian noticed th= e TLS mismatch. I don't think it will matter, but TLS thread model stuf= f always gives me a big headache. If the following=C2=A0fails to apply, jus= t copy the JEMALLOC_TLS_MODEL line from i386 to arm. The default changed el= sewhere, but this wasn't updated here.

Warner

diff --git a/lib/libc/stdlib/malloc/jemalloc/include/jemal= loc/jemalloc_FreeBSD.h b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/j= emalloc_FreeBSD.h
index 34c86271ab2e..bd6850ebd95f 100644
--- a/lib/l= ibc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h
+++ b/lib= /libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h
@@ -26,= 10 +26,11 @@
=C2=A0#undef LG_SIZEOF_LONG
=C2=A0#undef LG_SIZEOF_INTMA= X_T

+#define JEMALLOC_TLS_MODEL =C2=A0 =C2=A0 __attribute__((tls_mod= el("initial-exec")))
+
=C2=A0#ifdef __i386__
=C2=A0# =C2= =A0define LG_VADDR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32
=C2=A0# = =C2=A0define LG_SIZEOF_PTR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A02
-# =C2=A0define JEMALLOC_TLS_MODEL =C2=A0 __attribute__((tls_mo= del("initial-exec")))
=C2=A0#endif
=C2=A0#ifdef __ia64__=C2=A0# =C2=A0define LG_VADDR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 64=
@@ -38,7 +39,6 @@
=C2=A0#ifdef __sparc64__
=C2=A0# =C2=A0define L= G_VADDR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 64
=C2=A0# =C2=A0defin= e LG_SIZEOF_PTR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03-# =C2=A0define JEMALLOC_TLS_MODEL =C2=A0 __attribute__((tls_model("i= nitial-exec")))
=C2=A0#endif
=C2=A0#ifdef __amd64__
=C2=A0#if= def _USE_LG_VADDR_WIDE
@@ -47,7 +47,6 @@
=C2=A0# =C2=A0define LG_VADD= R =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 48
=C2=A0#endif
=C2=A0# = =C2=A0define LG_SIZEOF_PTR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A03
-# =C2=A0define JEMALLOC_TLS_MODEL =C2=A0 __attribute__((tls_mo= del("initial-exec")))
=C2=A0#endif
=C2=A0#ifdef __arm__
= =C2=A0# =C2=A0define LG_VADDR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32<= br>@@ -69,11 +68,9 @@
=C2=A0#ifdef __powerpc64__
=C2=A0# =C2=A0define= LG_VADDR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 64
=C2=A0# =C2=A0def= ine LG_SIZEOF_PTR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03<= br>-# =C2=A0define JEMALLOC_TLS_MODEL =C2=A0 __attribute__((tls_model("= ;initial-exec")))
=C2=A0#elif defined(__powerpc__)
=C2=A0# =C2= =A0define LG_VADDR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32
=C2=A0# = =C2=A0define LG_SIZEOF_PTR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A02
-# =C2=A0define JEMALLOC_TLS_MODEL =C2=A0 __attribute__((tls_mo= del("initial-exec")))
=C2=A0#endif
=C2=A0#ifdef __riscv
= =C2=A0# =C2=A0define LG_VADDR =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 48<= /div>



On Sun, Nov 16, 2025= , 8:42=E2=80=AFAM bob prohaska <fbsd@www.zefox.net> wrote:
On Sat, Nov 15, 2025 at 04:08:50PM -0700,= Warner Losh wrote:
> On Fri, Nov 14, 2025 at 12:31=E2=80=AFAM Herbert J. Skuhra <herbert@= gojira.at>
> wrote:
>
> > On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska wrote:
> > >
> > > On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote:=
> > > > Op 12-11-2025 om 23:25 schreef bob prohaska:
> > > > > For lack of any better ideas I've collected so= me of the assertion
> > failure
> > > > > /tmp files by host at
> > > > > http://www.zefox.ne= t/~fbsd/assertion_failure/
> > > > >
> > > > > Thanks for reading,
> > > > >
> > > > > bob prohaska
> > > > >
> > > > >
> > > >
> > > > A really uneducated guess, but might the update of jema= lloc [1] have
> > introduced some subtle issues on armv7?
> > > > You can try reverting:
> > https://cgit.freebsd.org/src/commit/?id=3Dc43cad87172039ccf38172129c7975= 5ea79e6102
> > .
> > > >
> > > What is the required syntax? Trying a simple
> > >
> > > root@generic:/usr/src # git revert -m 1
> > c43cad87172039ccf38172129c79755ea79e
> > > generated a torrent of conflict reports
> > > The source tree is expendable with no valued customizations.=
> >
> > Try:
> >
> > git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8
> > git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353
> > git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102
> >
>
> Do you have to do all three? I'd have thought only the first one w= ould be
> needed.

Necessary or not, it seems to have worked. No errors were reported and
buildworld/kernel has run successfully on two of three Pi2's. One of them has rebooted and run an incremental buildworld using its new kernel and world.

Next step is to run make cleandir twice on that machine and try a
clean-start buildworld/kernel. Those results will take a few days.

In the meantime, is there any explicit test to see if the reversion
worked as expected? Searching for null (no error) results is slow.

For example, Peter Holm's stress2 suite found lots of mischief in
years gone by, might it be applied to this sort of problem?

Thanks to you and everybody else for your help!

bob prohaska

--00000000000064e2d50643b9e032-- From nobody Sun Nov 16 21:11: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 4d8k7p5Bq9z6H6bG; Sun, 16 Nov 2025 21:11:18 +0000 (UTC) (envelope-from mmel@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d8k7p4hQ6z3PWW; Sun, 16 Nov 2025 21:11:18 +0000 (UTC) (envelope-from mmel@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763327478; h=from:from:reply-to: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=B+if8e3KuhPovBBBjlckAx7Y1V/Ducg2ltSt5Z27pQw=; b=sQkf47V0xQPXGP03V/0lFZ2nHKaDf03iT90B8N4kEeFXwZN+u+p9we2pr3w0I69galLfNx laIPUzQcL9gReFMXjnBtJVZjr+8x+4mibpXE5kOb5ZSfmI/tR6mTlk3ctUtaE9sSy1dKO/ J/tONpkHTDorENx6dKhOHeSrHtGRKZ9x5NgGd5iMV2Jbpawa0NMraK0aA5BAImkhC83KBo 8RAs+0eNSY15N4JfoITvSoI6/2KUEy+F6BrPddlzUyaFI9jjk+uYqvVNUvhRrc2ivTmhtD vONQdP723LqN6iMzRww5TyYA/vMCGGhu9YchlO5zcz0RenFmNsxAJt2D82rKzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763327478; h=from:from:reply-to: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=B+if8e3KuhPovBBBjlckAx7Y1V/Ducg2ltSt5Z27pQw=; b=lNpF502+LVKSpF1DkUx7NYEsnSQ6r/CuMXdSL+wIfnha7pmTizAtdZMksxlW5fszn+qonP P2TLuMx+w3mjq1PqiAulktW9yFIVXFinmNhJbYLMc3LsI7nyo/3CehACvWyivKuIYo7kDm qwCkpNukZ1fpWUwMv0Z9NG/kJ5ji4VQWkHHn0v18V+yiVz0y/a417ik6jOgIIyLVVcFfZ/ 8vfM13Xt3vjzsdShhZkn4XRN9zcH91VgjFRengqPgmNMux0Ldci9KHZ+glH0yMNh73oAtL W9tcljGYFY0JcJ/q3iHbqh/23yjirmS7AYSzpyujHVgJuS9IH3ktrFLAvmz/Qw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763327478; a=rsa-sha256; cv=none; b=i/s54jcdQ/qHEfqnrsBok6CMeyKAlVNJaJTIk/16tcSX2hvVPawKNff7FOi1GM99rd+iAv UA1SmxCTXcdTXE50ssC6tbawdCdDaAHNPqpyIFGr3FDB5m5lJEQIHKcmOdUdYr04zLtdwa VqfKsvlzQqUwi97Y8CBvkkZuTlP+7QCKgPKdOi9YMjPtXtirTeLHNbl5n2bv/Z/mACYvs5 oDCT7ZN7kbH/1x/7YXWOfND+0jeF1HlXwJwDe+KUysR0LCi+TLYmbZOiEXpsxKKdUhLqqw XSr8txMOd0Fr1d8bvoh8i8Twm5DOyvOF6yUaRPGQ0l2AaEM+13EH3vuY92knxg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2001:67c:14a0:5fe0:5d57:b56d:2102:8df5] (unknown [IPv6:2001:67c:14a0:5fe0:5d57:b56d:2102:8df5]) (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: mmel/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d8k7n3cNnz10L0; Sun, 16 Nov 2025 21:11:17 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Message-ID: <0a93ab5f-3fdf-45a0-8b32-2df5ef4ad60a@FreeBSD.org> Date: Sun, 16 Nov 2025 22:11:15 +0100 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 Reply-To: mmel@FreeBSD.org Subject: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld To: Warner Losh , bob prohaska Cc: "Herbert J. Skuhra" , "freebsd-arm@freebsd.org" , FreeBSD Current References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> Content-Language: cs, en-US From: Michal Meloun In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 16.11.2025 18:51, Warner Losh wrote: > Maybe try main with the following patch. Adrian noticed the TLS > mismatch. I don't think it will matter, but TLS thread model stuff > always gives me a big headache. If the following fails to apply, just > copy the JEMALLOC_TLS_MODEL line from i386 to arm. The default changed > elsewhere, but this wasn't updated here. > > Warner Unfortunately, that doesn't help. I'm out of ideas on how to debug this, all of my attempts have failed. The problem only occurs when Clang compiles a larger project and is intermediate. Attempt to compile the clang generated reproducer is always successful. It's clear that the parallelism introduced by make plays a significant role. But the system never reached an OOM condition before failure. I would be grateful for any help and ideas on what to do next. Michal > > diff --git a/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/ > jemalloc_FreeBSD.h b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/ > jemalloc_FreeBSD.h > index 34c86271ab2e..bd6850ebd95f 100644 > --- a/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h > +++ b/lib/libc/stdlib/malloc/jemalloc/include/jemalloc/jemalloc_FreeBSD.h > @@ -26,10 +26,11 @@ >  #undef LG_SIZEOF_LONG >  #undef LG_SIZEOF_INTMAX_T > > +#define JEMALLOC_TLS_MODEL     __attribute__((tls_model("initial-exec"))) > + >  #ifdef __i386__ >  #  define LG_VADDR             32 >  #  define LG_SIZEOF_PTR                2 > -#  define JEMALLOC_TLS_MODEL   __attribute__((tls_model("initial-exec"))) >  #endif >  #ifdef __ia64__ >  #  define LG_VADDR             64 > @@ -38,7 +39,6 @@ >  #ifdef __sparc64__ >  #  define LG_VADDR             64 >  #  define LG_SIZEOF_PTR                3 > -#  define JEMALLOC_TLS_MODEL   __attribute__((tls_model("initial-exec"))) >  #endif >  #ifdef __amd64__ >  #ifdef _USE_LG_VADDR_WIDE > @@ -47,7 +47,6 @@ >  #  define LG_VADDR             48 >  #endif >  #  define LG_SIZEOF_PTR                3 > -#  define JEMALLOC_TLS_MODEL   __attribute__((tls_model("initial-exec"))) >  #endif >  #ifdef __arm__ >  #  define LG_VADDR             32 > @@ -69,11 +68,9 @@ >  #ifdef __powerpc64__ >  #  define LG_VADDR             64 >  #  define LG_SIZEOF_PTR                3 > -#  define JEMALLOC_TLS_MODEL   __attribute__((tls_model("initial-exec"))) >  #elif defined(__powerpc__) >  #  define LG_VADDR             32 >  #  define LG_SIZEOF_PTR                2 > -#  define JEMALLOC_TLS_MODEL   __attribute__((tls_model("initial-exec"))) >  #endif >  #ifdef __riscv >  #  define LG_VADDR             48 > > > > On Sun, Nov 16, 2025, 8:42 AM bob prohaska > wrote: > > On Sat, Nov 15, 2025 at 04:08:50PM -0700, Warner Losh wrote: > > On Fri, Nov 14, 2025 at 12:31 AM Herbert J. Skuhra > > > > wrote: > > > > > On Fri, 14 Nov 2025 04:44:55 +0100, bob prohaska wrote: > > > > > > > > On Thu, Nov 13, 2025 at 09:11:51AM +0100, Ronald Klop wrote: > > > > > Op 12-11-2025 om 23:25 schreef bob prohaska: > > > > > > For lack of any better ideas I've collected some of the > assertion > > > failure > > > > > > /tmp files by host at > > > > > > http://www.zefox.net/~fbsd/assertion_failure/ www.zefox.net/~fbsd/assertion_failure/> > > > > > > > > > > > > Thanks for reading, > > > > > > > > > > > > bob prohaska > > > > > > > > > > > > > > > > > > > > > > A really uneducated guess, but might the update of jemalloc > [1] have > > > introduced some subtle issues on armv7? > > > > > You can try reverting: > > > https://cgit.freebsd.org/src/commit/? > id=c43cad87172039ccf38172129c79755ea79e6102 cgit.freebsd.org/src/commit/? > id=c43cad87172039ccf38172129c79755ea79e6102> > > > . > > > > > > > > > What is the required syntax? Trying a simple > > > > > > > > root@generic:/usr/src # git revert -m 1 > > > c43cad87172039ccf38172129c79755ea79e > > > > generated a torrent of conflict reports > > > > The source tree is expendable with no valued customizations. > > > > > > Try: > > > > > > git revert -n -m 1 8ebb3de0c9dfb1a15bf24dcb0ca65cc91e7ad0e8 > > > git revert -n -m 1 edf9a2fae94a4b0ffa11d40ce52a48a609da9353 > > > git revert -n -m 1 c43cad87172039ccf38172129c79755ea79e6102 > > > > > > > Do you have to do all three? I'd have thought only the first one > would be > > needed. > > Necessary or not, it seems to have worked. No errors were reported and > buildworld/kernel has run successfully on two of three Pi2's. One of > them has rebooted and run an incremental buildworld using its new kernel > and world. > > Next step is to run make cleandir twice on that machine and try a > clean-start buildworld/kernel. Those results will take a few days. > > In the meantime, is there any explicit test to see if the reversion > worked as expected? Searching for null (no error) results is slow. > > For example, Peter Holm's stress2 suite found lots of mischief in > years gone by, might it be applied to this sort of problem? > > Thanks to you and everybody else for your help! > > bob prohaska > From nobody Sun Nov 16 21:34: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 4d8kfj6DJQz6H8Jk for ; Sun, 16 Nov 2025 21:34:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.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) by mx1.freebsd.org (Postfix) with ESMTPS id 4d8kfg1Fw8z3SJv for ; Sun, 16 Nov 2025 21:34:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Mx9qWgOF; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763328872; bh=nduHpDBQgztOS8HlmfRavbPmIa1ENA6KrxCIQTEgUrk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Mx9qWgOFRI7hbGz8/LUqcVJQTX8ApkwKntrlNGVTTAM0MjwkLOO7JyLteGSGyxz43JA8AeTGldQkM1Y6c9JjoWAlTyTVEWcEXAtCJcsK0x/jOc1KC4lBq6ljj3JucbtcUJcG0gYYCyhJLM9N/XOj/FesEEwz3hs+q5ZQJZuaI3wMNLQC/Zy7uRsqLUu2RMddrvJw4SK8ff9C4FjTBTcVnlY+KgN0DYvA5/XENEEqL24O90WfepC3837lzq+1Rmn2Nm0rl4MfEos7AJ3weWTbqP3vTOOyreJMhvrDVtOgE8pJJKDfSOOWpNEVu7TPmvTdTklXLDm497CmMtJ4GzItlg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763328872; bh=CICxHCEqxNzRsgH429J3XGL7H61c6yDJ1TDOTT6w6z+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=XXe2+bKMDMuQAsQttXJFH9VZFWRgu6J3XXZIAcZ/+OkCkhQAk9fSbbT03QMxV2f4bwdo2XNrJ+JSw2D+pgQsWNt2W3hSdmoyCJ5EBIAiJFxUGCt4nCpvBT+Qp17jkHjgKsSFZny9ukbG5BPectP3yMzfLdqvx4AV97rutdMfRSIJJi/7P4mzDlYVAAPibNoYwOqXTkjn6rsMzxD2cx9zTxBCxUSiPr0sM1I6WJi8I2v4z9eRlwoRAGkdW1ediqMCmfJmclX7xTjubFhKOdrTlir7xOe5+YdYah3NQrzGwdAUliAVelZzVo7rFVQUz6jWYQnWx4lgua7xvG/C2g9/KA== X-YMail-OSG: Y0IBsl8VM1lLcJeXfnLSQo26zWGQWKGv2cfUOCvLfyyCV3Gyew8bqT4g1vb64ZE dks_TMLcIvDMGrDuze_f9VIoljmWqXAZJwGJqzl12bDz3Nqw_SZ1maGEXgDa1IadX5.2y_HS3GN8 sAlCTbP1oSzmH4ECmlGpeOJ0yZoblQw_KxB9YCt39l1l789TukoHkt4KFYMKMZVgDrxUzl6gVSc. i_JLypmONpccCo54hOBec8bn44DBFaVQRibfbWhjE6_kyLGGtC.OZKmMLfJoskMaLPdLJaO3lMh4 wZl7WO.uwOxV3XpuVpxVTP3I1OwX.mDjfVNV2_T8HByY6stLOOtaPCJelIDXrPb7n6Jgw4Dkzdys Ivtc609GfCPqdOCwib7mna9FXYyWMRlN56cb_cmQqmsxpvugLXY9Pm_Yj5QPYriHk9F0jaty4hl4 8ME6_.DFHO8j7jJ1yu4Jc7v1DVKxBQZ9psPCIyUPT7yy4oDky7xX5hK0YAP12n1Ou.zFynr2jJe9 kOzbF95U7dTwFyzxF1vHrEtlHKhMeetL8RtPssrKHLzAiN8oqeRHF0l5o._7N.sc2g7lxOdgv1gA ivXZ_jwqLosgyBAGW.8PM.4A.65urxLm5wM0vHgxQRkEN..LbSuHl_wr817m2709i1aBsSyKlqD5 _lJ61VIhLBe5m8JhUyZ9NF6j9SpRqvQ7AsF8jqBUHYolGWZFkCX9ogcI8LwVlEk8hUyOSRwab7LG G1160Q_OO_QBkLuTrKCUjwxwSaNrgtZskoomeuxXN4wEeGwm3W5Zw_yPBQFkE0X1eeXvDaZKCz5n OPBHn5bAok8_JUQfwDDlTnNFeWcbJYy6sxZL6hgSdoTpT7FpEqI3kHhEYi9d0riFWdYfF8w47sdm Dw1HKVYCGUbmDjJJ2.V8Qpgr0G0HyVIC1Fy1X0.5h8o0pRHK34uJDccLFHAjE5anbm5kqAB.QnzW VjaUa8Kt0HGfH7wPmH5bROKdOh27CRmOQ5s4X5exnTkYTu_jdSzsXtC_x5xnpRUJpMFOMzUZWA1v IUdxY79_m6QIXAfkI0mA7ppbiYVSKGvWrLYg_lF3p5rqKiEaBXB41pHVHlCLuqkXvadEGmvTBWY7 qfa0.z64mxn5NqASVbEsvX09yaLtgq72puVO5HqfOq1GnISlLH5xOQM8Y6CSPk6IOkgydxuiZwau b.FSvNrhdEkx3z6GoFIg2GyL66ZyXawJhaP6xHOii9DI9OO.kcYWHzMqVl0yWHppkNkPE94QXVMM xQFs5gd4WZgU.iCEiehmVLM9kmWqYRahdVyRuvzzs23FgEzOUpFLmjnLnxxMu3cNooN0VR0.kAi0 EY6oGJC9MblS3jCQQGpIudgFCNgsjiVUf2RocMYkui428uAW5UfvjP7yn2pVBNpTf1qa9ADupaMm U347GdWRwvFGy9tK6u5NaUqE1WeUxumZGglrEMdjYF0fobB8hjdqELc2Yw6sR6YCanvAFBTLgil. GWahgABeXCHGFS.EkFQdkttyns6r09Q3voSXzBRKo8EiA1jmfAE5W6PlV4li2HJDpmbBclJjfCus yydAnIZpthFe1pb1swGcmxnjahgYxj79bJJPo_FDJzxjLsYYvBWQmR4WYR5MPn8pttqnC57eqJTR hjDc_NQA779Lq7ASnOCb_vTFn4Tcbc5uaZAoY9YEYLlgDHhdVXJdaS1lG6N0s8yn1ApU.SpuL.FZ 1Xnap9DIlS2JnV2RNE1cHRqsOPn_dxF7eMpOMmTXgBJhY9GbmbpTUnBDlkFuc37J03fK1o79cXps VOlp7eO7g8s5zw2PmFCRDqHSgpqsioxbLZ7iaUgGcANr7QNej3QNj3kGkCZW2KA4stCoYtD6zenX JV2i54F4ig5J5eiv1BeAH0Uswh1ceLWONuWyABd4E1p_cJRPccsUUhDCsK7BfQTcofUAfjDzTZj4 lsuAAcGt8xUYQ5dBifvwBEmT5keFSfDBWpvA_gtY5Qkhr2bbfUKxWYaPSxP9naqxGFPb42Q1MGCS l7HvYIE3ziy6onuCrS4Qqp979WbR5_4jH8yUzGJS26eyRk0O0g0zbuJbxu5sFmeGZqBXLhwLWVBP gkGOhC1g3H69NjUgPU0KeGmatWhyH4WHFaYxBlIc9uuFBjjfjX7o8_0B6Ql7T2zJKqAE1dAIf2_X _wyd4zloRO.RTelHSZs8GqZjBhXCUA5CdI1AnOWZHMIPq3yPxf5MDb4X723UCSJDnZmYIFHPsV10 1GtL_iv2Id4o5jLMurlBpfOtw85WIClfq1ydUFe93yf4Wp4g3yahNpdvtiFJPHDc1fGUOQnkHMio Ky2D51GVJ6hGSlf.FUFvN9Q-- X-Sonic-MF: X-Sonic-ID: fd86cdb6-e36d-41a8-b00c-87bb06422dc7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 16 Nov 2025 21:34:32 +0000 Received: by hermes--production-gq1-76c986f798-2d5kj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 898560d7fb6d37c4aa4d8a9f27ab9dd2; Sun, 16 Nov 2025 21:34:31 +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.700.81\)) Subject: 15.0's and main's [so: 16's] jemalloc man page reports "This manual describes jemalloc 5.2.1-0-gea6b3. . ." but 5.3.0-0-g54eae is in use instead for 15.0+ and main 16. Message-Id: <6C625281-B892-43AF-AD87-87950556EE02@yahoo.com> Date: Sun, 16 Nov 2025 13:34:20 -0800 To: FreeBSD Current , FreeBSD-STABLE Mailing List , FreeBSD-pkgbase@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) References: <6C625281-B892-43AF-AD87-87950556EE02.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; 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]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(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)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from] X-Rspamd-Queue-Id: 4d8kfg1Fw8z3SJv . . . LIBRARY This manual describes jemalloc 5.2.1-0-gea6b3e973b477b8061e0076bb257dbd7f3faa756. More = information can be found at the jemalloc website[1]. . . . https://jemalloc.net/jemalloc.3.html reports: LIBRARY This manual describes jemalloc = 5.3.0-0-g54eaed1d8b56b1aa528be3bdd1877e59c56fa90c. More information can = be found at the jemalloc website. = https://cgit.freebsd.org/src/commit/contrib/jemalloc?id=3Dc43cad87172039cc= f38172129c79755ea79e6102 has text: = --with-version=3D5.3.0-0-g54eaed1d8b56b1aa528be3bdd1877e59c56fa90c =3D=3D=3D Mark Millard marklmi at yahoo.com