From nobody Sun Nov 23 23:59: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 4dF5Xr0MQSz6Hfcf for ; Sun, 23 Nov 2025 23:59:40 +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 4dF5Xp4rvRz45tV for ; Sun, 23 Nov 2025 23:59:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qxI6oYLB; 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=1763942375; bh=+n0tVh6Ilztc9084iUP2L8ZSS2FvMXXmLaxJ3gG/MC0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=qxI6oYLBF9LHONaJWt4Hbk+TwGA3L2mLJHNF83q1wrjk8Dd6wlgTyelzPbXfiTIaG7MNoUlNSeLLGrewC5hg4+igEqfydm+nRK2+RCn2LrjWWm8jJuDlsLkalI7ajVuoCS/AU8n/qlP6cleqlLfsp87hr/9CBTPYRRZPxWJbtlssglhvr+QJ+bzgNYC8Yi2OEntSRKwxSGatoduDG+YP23KLsC1pDngnFIpPyf0f0BiltzjSr7q4FxpxIDmbDFxK9+anL9LTZ5b2JAZYtxp+mZs8ztdHYm7lvMohbVbnT8l4cu6BJESp5DDkI27dvQZWTcq7y4xjv9cMul0llrotAw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1763942375; bh=JKCpR2GUe4pRtE4eeazqUGVCk/NsGfdCjJkC8GYeLgW=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=r7Cmz60iQOYI0rF6ii/y4IRb/O7ZKtBRXoQ0fQCeI6KF7ESlh3ocOEP42bJnI8duonMjJdPAdhf4X0dFpRdbZ9u3TKwTFaStkTzI8FDr5mPYR9nAXvgCt1M3yUrtega5SCBc1UPFBVPjJxf+PP3JlCCrHIsVAnHQYV/BzHtzZ10OqQSwIsndfN1xN2J4hPkyJS/XdIxbwRBb7Z8t5X20MZ9ksBnfFzYStqlYD1Wn5qydqrRBd7A/rhQXb+k+/yhzPE1aBj038Q0Vgio/c+a1bBU+kQXLNayBQ+/1JOWAs7Fw8OSq3cjrNYh/JsqS940s99+Py7M/T0zBp+HGHDwnbw== X-YMail-OSG: cbl0V1kVM1nyafs4wEpOMrgxjdSXAYeW7lRu0hIyEv5GEU8rQs6kXt4gDjQCZwc rFm3kvahBpd3bq2Kp_kGoGy27MTXsro6EWkHH5PhPMu7xvcnvQog32efXiA3Cj91jRVh4JvwzgRx t6rkDkt1AJvFodne.1AD0_KUwC3F1jdY.fTs_SlX_KPnL_2aHazGTdxdaRsRKOQSv2v4ccSSzBJ2 E0fPL24Fjdp3WNysXpzqCi0GmXNdOGnFKZc6Zw5HrB1ApA3ldb2siWkhqQk3wSN7iogqSjFcrWWG V_vcqdFGgpZ7o.EjRIoce85QHUbcfLhkpC7XXxvYBQoSSOTE6DweXAAFPNPDSi3DIz3z3FS2PZPS az7HH3.i3Z3W_TfyBV2BjyPRlxuZi2M1xiLG63oxAMCNH9czFHYlYm99nsAIFHXuZAk43jaYfA7S dbLCERPDIiH1FfA.3jES4_IrAKhMgGVXxP0YrUotynriC1PWQv22NCnR3LU40GE7IVLn5wKWW_u2 CJsRUVah4DALMUeWwqSMMbBDoKomVxf1eU_6wXmutpxBRlUykmtOPSFPkmHLex4DTy1iFdt8jOjN mbVK4_sX6FxGlIykEcLAYX8L7FltHtxLohbjObfqmHvPCyqwgI15bZxUBcnY_oC3RY8D3HrQkvTV LDmO2ZezKWqjMCVBwnEwcCFKE1D_IsYd1eESyAB5xRt9QcOFoYLqiNDOJ8UwgpGLnj2yr3_5Ec76 _j86c.2VJyfRr0o_Ic.swcXYj3yPDTxVTK17SsGjKfkv3H3tsi4SQ8UjhwNxDK5dRi8JqxGk3Ec4 z8rMrwe.le52T3t8f9gMrYwKgu7hPGh6AFIhy0kG2b76YclRY_jUuYgosfZb_mHpDYufEThuugsx MSC5ii0ZxlQ8qg_m_17p_h6DkwdJAxtqHMZr5jBdMtbXUJv5u6JG1TH1iXxx3QiFxQ1E90VjrLN0 f6HieEpiOJ6dG_U_oiK9jqQhIGlQwLAoFnuMeCbUjQSCHcJkib03Mxpb7L9t3wqOXgXAz_wPc0I1 EKT7h6ij1TLamqMyIvWqrkwuLp7_LfxTXWDV8gVnhBJKsFu2gXqmKjyQAmQC3kqe7KxvSWz7zoNX YbfjtSXpKHnQLJm4pH2CiSyBYFI.AuWoEvSbM7.l6IKDDlv3lJeC6uskhwLaCMO_kW6pGe6oG0az cZrn3inKWfZF.HwjFy3mIa3lymWwzwuOGYwXsFm0Akv7VjoiNiSUIF0MOX828TYsJDen_vaE3Enw lL_l5U1XbmK4MYA2n2FV1IL.4_NfexaFKBfeBbaOiygJR5aTyjP9nBs8tX7pxZbLU_oaVgVzswNN malrfnUB..pM.mqTCca4y1lR_GRajHH3XrE1x0ZDLU7Kdi6FJTKHPFWGFe_aObxXHoavTz0V2Xp7 eNvXOaFu9rUvstdxJ6K9KLFavev8UWu.uV_p_wglrdzTwXlUEkAs6dgxLtf0tlGC_8OcN7CdBaz6 7uOg7uBmQzm6MrinZ7LQh.xHDPZGuStHS.V.pzChZoS8UkOvjmZ15_2Vd9onX3vb6I.saSr3DPUe ooBNxOEM7aJ2_.9P5W3Sn5OoZkecz_Pbydz69SdhxTggr3rODrLa_uPq18MBMur6CLtOZczt8lrY vS6APOPH8sIVk.JLZgkFgaIk9DqrEtPdV7zOpp5wgqxpP77Rw9R.UzVaAtU3jqx0vBD3D3lMna8q 7vU8S6O2PDAzCzQwrLr2AZiQYSl4zMIf9zLxVL.Pz0s5Il46OIsCKkJjoSFzxCxduld3Y5w24CA9 wWLZLruaGKxLdQmlBikUybrfm2A3doPSw1UZ3tVNc3aaC0wEy2NbiJNMr2DRL8TYGDLC0vXeO0dv RMihxmJbsqfj.xfhGb1pMxkwRBQAfUuZqAnL52S1IYtB9dZDdDOY.9Ompl42tF90KAni5zmjrecS PQxbI5Qx1mT3kKtf1lmeDzIgrW9h9bWlLPtLfa9zMY8fQUQyKadtPWyzws399fn.WT8VTnJeufsQ nJ34pTOrLst0IH9Z7XMYaYxkHmnWBlJFvUZH2j1RVmWwFr.jVwakAtOjH3lPgWL1b9jQN1Pz7F6J cRfn9kQ8KMuYoYc1CT2MHWf_PTRYuXytUVAT3TAiS0JkKQyjL3k7gNB6a4tVkh6a9NLL3ygMnk6A xNS3WywNPUjrRZe7Z6bXK5SLEuP80nZ9GhNQIBiNYYfPGUXKm0eIcFamuXURLJ0Jz4Q7QPRjW89L rqYIxRWG7eeT79CzKSETGp5dH0NGPoc4XFb_lqaRfhBinTPcsbFzBN_F2XUvdhxP6qnTBfIkTiPi 87w-- X-Sonic-MF: X-Sonic-ID: 2a4ed339-bf00-4e7c-aeb8-330de1981c73 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 23 Nov 2025 23:59:35 +0000 Received: by hermes--production-gq1-fdb64d996-whpwx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e9f7609bc243893704c202b5e279dbfe; Sun, 23 Nov 2025 23:59:31 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 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: Re: changing from pkgbase to regularbase [ /var/cache/pkg/FreeBSD-*.pkg as well? ] Message-Id: Date: Sun, 23 Nov 2025 15:59:20 -0800 To: polyduekes@proton.me, FreeBSD Current X-Mailer: Apple Mail (2.3826.700.81) References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; SUBJECT_HAS_QUESTION(0.00)[] X-Rspamd-Queue-Id: 4dF5Xp4rvRz45tV Dag-Erling_Sm=C3=B8rgrav wrote on Date: Sun, 23 Nov 2025 17:12:08 UTC : > polyduekes@proton.me writes: > > what is the correct way to depkgbasify? >=20 > There is no =E2=80=9Ccorrect=E2=80=9D way. Here's what I would = suggest: >=20 > 1. Make sure your system is up-to-date and consistent and you have a > matching source tree installed: >=20 > # pkg upgrade -y > # pkg install -y FreeBSD-set-src > # pkg autoremove -y >=20 > 2. Make a list of non-pkgbase non-automatic packages: >=20 > # pkg query -e '%a =3D=3D 0 && %o !~ base/*' %n >packages >=20 > 3. Delete your installed package database: >=20 > # rm /var/db/pkg/local.sqlite >=20 > 4. Reinstall non-pkgbase packages: >=20 > # pkg install -fy $(cat packages) >=20 > This will of course also reinstall all dependencies, but we are > deliberately only specifying non-automatic packages so the end result > is the same as what we started out with. If we had made a list of > _all_ installed packages, we would end up with everything now being > marked non-automatic, and `pkg autoremove` would no longer work > properly. >=20 > 5. Populate /var/db/etcupdate so it will work when you later upgrade > from source: >=20 > # etcupdate extract >=20 > 6. Optional but recommended =E2=80=94 disable the pkgbase repository: >=20 > # rm /usr/local/etc/pkg/repos/FreeBSD.conf >=20 > (this file will have been created by the installer and should contain > a single line that enables the FreeBSD-base repository; without it, > the repository remains defined in /etc/pkg/FreeBSD.conf but disabled) >=20 > You can also remove cached information about the repository, which > you will no longer need: >=20 > # rm -rf /var/db/pkg/repos/FreeBSD-base >=20 > At this point you can replace /usr/src with a git clone and upgrade as > usual (`make -C /usr/src -j1.5 world kernel && etcupdate -B`). >=20 > There is a shortcut for steps 2-4. I think it is both sufficient and > safe, but I don't know pkg's internals well enough to say for sure; > perhaps bapt@ can weight in. First you need to install the sqlite3 = cli: >=20 > # pkg install -Ay sqlite3 >=20 > You can then use it to remove information about base packages from the > package database, leaving the rest intact so you don't have to = reinstall > them: >=20 > # sqlite3 /var/db/pkg/local.sqlite \ > "delete from packages where origin like 'base/%';" >=20 > If you choose this route you can also drop the autoremove in step 1, > which I only put in to shorten steps 2 and 4. You still have to = perform > step 5 (and optionally 6). At some point after one is no longer dependent on FreeBSD-*.pkg files from pkgbase, one may want to recover the disk space from any: /var/cache/pkg/FreeBSD-*.pkg files. # ls -l /var/cache/pkg/FreeBSD-*.pkg lrwxr-xr-x 1 root wheel 49 Nov 15 15:48 = /var/cache/pkg/FreeBSD-acct-16.snap20251112131218.pkg -> = FreeBSD-acct-16.snap20251112131218~d117264470.pkg -rw-r--r-- 1 root wheel 48106 Nov 12 15:39 = /var/cache/pkg/FreeBSD-acct-16.snap20251112131218~d117264470.pkg . . . (My file ownerships need not match yours.) # ls -1 /var/cache/pkg/FreeBSD-*.pkg | wc -l 1032 (Not that you would get that specific figure. I tend to have all the FreeBSD-*.pkg for the platform installed.) I'm not sure of what well fits with the above steps 1..6 for this. Possibly just as a step 7: # rm -f /var/cache/pkg/FreeBSD-*.pkg ? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Nov 24 00:38:39 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dF6Ps2D2Fz6HjX1 for ; Mon, 24 Nov 2025 00:38:41 +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 4dF6Ps1bqMz3C1p; Mon, 24 Nov 2025 00:38:41 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763944721; 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=MNcsEWtHhTwA/1FzuQ6w9CMTJRYUWfNUydYKJm7pEnM=; b=OvvM3UP9QJMxzuU5vX9M78UXT0FLx59HF/ZWWv+5Pwjr+0EqABO/IjtkyTbGgRPm/b7isc Cdnk04ueBHwlmGCKxdaH1A0oAZcxqRDEFuAo0LqAmiayKa6w8RymkCjDQB/XQJazPOp5u7 uyM8QkrOmtnXH8C6o1913rPw/I9et8QWyiTf9Rl1wsPi1UIchQsE5lnjQuQ8RIqzBvf1y5 yEstAgZQVoyIQ8racDVqXJB1n6BubHbzUKoH81W6O5qDNUpSnlB4+jp5mzczjwT0PEPkWt V16CY9Msxp7SHeTJNyCjxtEB6CttG59qxj9WuATCKWGi5yL/Ge3ddn42iCcr8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763944721; 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=MNcsEWtHhTwA/1FzuQ6w9CMTJRYUWfNUydYKJm7pEnM=; b=H6sseDhXBVql6rZgaS5omCfHkdoMzK5vqmHXNgEQSI0pvNN8rP+Hytth7pz9dhTbDygt4l XO6EYYBmjicL8TzwmLzOKzteqvFzTw/kJ33Yh7CM5PYI4+MpDEVvehu5McwzArzqIlk7Vp K55Wmv1/uZtn7qkO6WYU/RZ8k0suceWnF2PuTwB+ug37L8v8183NNFGKIGDWq3K/3HzwXV Ghqx2Mn1/OqX2BzVV3t7W7+jL+syUF66zYu9MZ7fkSRDH/SfkG2x18tQDzZokSk8t6DnRT zEAkwgEhXrX4VjUTCj8KPtq0ulImI9F73eSgeMxiRfNAffYAknvxnhYP+nSgVA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763944721; a=rsa-sha256; cv=none; b=iSliVFQr7Ygq665BpO7c53ZCl2z1qQkFQ22BgkgUOa/7h1qJO/hxTCtLK+nmTBy576tovq 7UXvpVQVaK/7FEEWSbj6v1Pr2RbtMg1jw8UotQ6FXy7mAwKy2Ndnb61hMSv703WpSfonEV ik1crZzEMQk8p1UHz7pwDbqDFk9lePFaRRZQlA196R4380QZ1rmr4wb2b0LjNeMRh5JyOm ju3aMBmhaO2OlAk4gyczfcAcud6w9IyMCud/LxEvCGS3K9ywD/4lhsnhOVH0riWpDnJBIx WD6QK0EjLCM44QCxfdUz6V7ufTdHgY6pgXzrx2PVLE3nE0W46vAXOHPEEfgJaQ== 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 4dF6Ps0FJ6zKBK; Mon, 24 Nov 2025 00:38:41 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id A798D8B9CD; Mon, 24 Nov 2025 01:38:39 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark Millard Cc: polyduekes@proton.me, FreeBSD Current Subject: Re: changing from pkgbase to regularbase [ /var/cache/pkg/FreeBSD-*.pkg as well? ] In-Reply-To: (Mark Millard's message of "Sun, 23 Nov 2025 15:59:20 -0800") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Mon, 24 Nov 2025 01:38:39 +0100 Message-ID: <86tsyk8dtc.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 Mark Millard writes: > At some point after one is no longer dependent > on FreeBSD-*.pkg files from pkgbase, one may > want to recover the disk space from any: > > /var/cache/pkg/FreeBSD-*.pkg > > files. `pkg clean -y` after either deleting the package database or dropping the base packages from it but before disabling the pkgbase repository will take care of this. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Mon Nov 24 09:00: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 4dFKXv0Bz1z6JLYG; Mon, 24 Nov 2025 09:00:31 +0000 (UTC) (envelope-from glebius@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 4dFKXs6mGNz4DRw; Mon, 24 Nov 2025 09:00:29 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763974831; 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=FZNW+KZ4tWLsyJNXTCZgabCclnBnYnRHAN8+vzet7/4=; b=wWU2qQOT+rJOLsJOGBt5mVh8oxtmdVCZsn/tS4F0gDPP8Iw5vY+7m8GEpkS5Z0HbBvauj3 yoTzKlnttcqA6kZ8X1DFnrbKWUUC42t2p1UWt6aPxWS7RTmcnHrGBEg/PP9vzPkygZBiYm CUxsfbQ47kM/C+pLtFfdi1kRQ665akxiSmG+PbkvMTWXit+YLO3shfEJtdRSZ3joO9Deh0 vOFglGjmg+KmBBPsmP2K6PnLpgGfAJdOu+H/1WnR1zJsFBPeg3zuDPRxcqyczGdcg3Ep8v eL0V/kEhATp4K9Fm2sOhg+Qr0FThAHipLicXqXgoIg5Y6XeGEhRszvzuGWy/Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1763974829; 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=FZNW+KZ4tWLsyJNXTCZgabCclnBnYnRHAN8+vzet7/4=; b=vP2h/BssB3lTKVvGUQw36rKFfOkmIfUk2jn9X26KuE3N28oSMyyArvrtrpTdjI8Jac8SEN NY9ujz3fbUwV55AgnWvvz12ONExn0pv3lxhLqEjR65VM4YKW1vkplfZpzzANA8XVPJ9tUB +f8nM9cZhhSXTdtd+cfvIgR7TYGi1v0g0GO8I519FTqyDIRhYNOFTYpN79IcyFZP6ukCX+ vltmH8ZKZV62jA4HET53uQWm9wXdfkeFB5wlwTdGqYJTJRM6kaa2E6xDsa/4Hr4toluFgy kG8M0qvVFFdlQ1IUOQxszME1sfv5dgzcTUcZOI8Ml5VXt33JhgPLekLxjuA0/w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1763974829; a=rsa-sha256; cv=none; b=PEa5d7XYNpCzy+IagZ2BXAD6a4p5gS1mcrKwafVv1XP2X4otmu9bTk3+sIGiFif4hd2/5O /0hFrqe5EgRoRlDpX47Th8K43mlZEQgOHncqnrl33aQm9UajH4EcnDxXou3LoNik+8I9R+ IPlCUKfForHQ1+N6LbP3Xs1nAsSQ+litLxfW6MhbYlOKZGyT0JQJkABW3+AmGkb+n3GyGU Uo+xA0jlwKjFhu/N/A7X6mwEhw2x1xoj7G046LFDmVPYH/y4q+7i5cCYVkiDZPanIUKLA8 kqrYpg52LeDCsA/3qcWyrIuG8f60kCiCHgxg7CuqK6gGqwUNxKQcxRO4PxrJDg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dFKXs4CW9zknb; Mon, 24 Nov 2025 09:00:29 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 24 Nov 2025 01:00:26 -0800 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: November 2025 stabilization week 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 Hi FreeBSD/main users & developers: This is an automated email to inform you that the November 2025 stabilization week started with FreeBSD/main at main-n282109-a067eb525e10, which was tagged as main-stabweek-2025-Nov. Those who want to participate in the stabilization week are encouraged to update to the above revision/tag and test their systems. The tag main-stabweek-2025-Nov has been published at Gleb Smirnoff's github repo. To connect this repo as an additional remote you need to run: git remote add glebius https://github.com/glebius/FreeBSD Once remote is configured, to checkout the tag run: git fetch glebius --tags git checkout main-stabweek-2025-Nov If you want to use only the official FreeBSD repo, then update to the revision: git pull git checkout a067eb525e10 Developers are encouraged to avoid pushing new features to FreeBSD/main during the stabilization week, but focus on bugfixes instead. The stabilization week runs up to Friday 18:00 UTC, but if there is consensus that any regressions discovered by participants have been fixed, it will end early. Once that happens, the advisory freeze of FreeBSD/main branch is thawed. -- Gleb Smirnoff From nobody Mon Nov 24 16:00:38 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 4dFVtf6FP0z6HQM2 for ; Mon, 24 Nov 2025 16:01:30 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) (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 4dFVtX2PQgz3spC for ; Mon, 24 Nov 2025 16:01:24 +0000 (UTC) (envelope-from thj@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=DNGWpK9n; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 103.168.172.157 is neither permitted nor denied by domain of thj@freebsd.org) smtp.mailfrom=thj@freebsd.org Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfhigh.phl.internal (Postfix) with ESMTP id D267C140014F for ; Mon, 24 Nov 2025 11:01:22 -0500 (EST) Received: from phl-imap-17 ([10.202.2.105]) by phl-compute-03.internal (MEProxy); Mon, 24 Nov 2025 11:01:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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= 1764000082; x=1764086482; bh=1Npq9tPN4V+Z7Ru4OdHxazcD31NSTMnSLeL QZ7vGW4Y=; b=DNGWpK9nrQlvOEo2KbeDrBbdztERJn6E6909CvZDNlQTiBKwzcy LupwNH0yDoa8CycA+MvGJyCmPkGOZM8wPQsA0T5qo70ovuJ0nGY6x87RRT3ptOX3 0FGIt+hdXPKpf9GMaWVN2Vh6ECdMRFkWYOhcwQ/yPyTvMTxnJOQfH7NK383IjsQS uSc2QinPTxQXAY+QU4gQ59umyE3qzv9J5x/mFafX1t08wcG/vT6l1gU/0M9+gEis yTZd0Tb16HG0e1HeNjN6kOsw+DEN/n90cDYro/XELmareMzB0rmq5TnxFdXzGHl8 oQiZj9CnZBy+vKqAr0dVWpUkN7NnAmWDm8A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvfeeltdefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvkffutgfgsehtjeertdertd dtnecuhfhrohhmpedfvfhomhculfhonhgvshdfuceothhhjhesfhhrvggvsghsugdrohhr gheqnecuggftrfgrthhtvghrnhepgfejtdffhfettefgudfhgeejleeigffggfeliefhud fhffeugfelleevfedtieffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepthhhjhesfhhrvggvsghsugdrohhrghdpnhgspghrtghpthhtohepud dpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghn thesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: ib75146ab:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 82DE9C40054; Mon, 24 Nov 2025 11:01:22 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface 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 X-ThreadId: AW70ofIrgkvB Date: Mon, 24 Nov 2025 16:00:38 +0000 From: "Tom Jones" To: freebsd-current@freebsd.org Message-Id: Subject: Some issues in the 20251124 16-CURRENT snapshot Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.28 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm3]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, DKIM not aligned (relaxed),none]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.157:from]; XM_UA_NO_VERSION(0.01)[]; FREEFALL_USER(0.00)[thj]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN_FAIL(0.00)[157.172.168.103.asn.rspamd.com:server fail]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DOM_EQ_FROM_DOM(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[messagingengine.com:+] X-Rspamd-Queue-Id: 4dFVtX2PQgz3spC Hi, I pulled down FreeBSD-16.0-CURRENT-amd64-20251124-nullhash-nullcount-mini-memstick.img to use for a test install and have hit some issues. 1. dhclient-script fails to start: Trying to get an address with dhclient leads to errors and a screen full of: dhclient[4273]: exiting dhclient[4273]: execve( (/sbin/dhclient-script, ...): Input/output error 2. the pkg base install path fails The ncurses view obscures the message, but I caught "FreeBSD-base has no meta file" I worked around the dhclient issue by setting an address manually, but I have working connectivity to freebsd.org at the packages install step. 3. the installer isn't restartable In some cases if there has been any error I'll get a message dialog asking if I want to restart the installer because an error occured. The only solution is to reboot and try again. If I have created a zfs pool from the installer, the zfs install step can't see any available disks and I have to restart. An install using distribution sets is working (well so far, downloading is taking a long time). - Tom From nobody Mon Nov 24 18:34:04 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 4dFZH952Cfz6Hf1S for ; Mon, 24 Nov 2025 18:34:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.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 4dFZH91khfz3FxQ for ; Mon, 24 Nov 2025 18:34:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=TFeHAWDv; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.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=1764009262; bh=p+pJVIlIOgJyomKqJgV8ZqkiwKnptGlUu37nXq1QYfg=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=TFeHAWDvg18oMmI37lDQ+JbhqVcbq/bSpk4forWV6Dg+04zAWrLEPBb70oU/qSWumqz8pcoSy2+StNTm+PDQ9MN7Gl3vum0Tcxbi5bOej0QcdMCXm4Iy5WvhRRlrXUML/lQ8mvDfSqQbRqQ1uZj56kOVCQ7MJTgKxkbEdIyOoeSE/hOgzbSBE0kQ1ezyQ2MGysu5w9p9gAGEa1zaLDSWicHX5ORadcjuVASYGWBN5wNFxK1uzxvOWCnQwN2o9Aycl8hEEb+nSl1/flYZ7ZQ1qS6SIROL8N4U7Y+pwIoyBTvwNhVKkj3dUhcyb77oohdwUa/7vSfB+ndSJqroAkkjDA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1764009262; bh=xA8S7K2Va4inbVb7zqI08iPxGlnHcc/1/xncQGND+zx=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=SZ8XNur9rX1F5GTv3LAz9kpixDcMTa1fuSpz/dAKD8mkcHBu8sVz25DfAPZggrEV5DBQD8P1Eq9sGKsIb/+/5/MyJbCWowadzkrNAGsQHFMvPRuEQErTRhHPRQffbnk5MPkosiZjjX3I1rk03A7pNFB8uFAbe6EgnkB0cAuX7sMPBxv0LLAxsoFOIiifzzXx0ABl/vsTQvIs1vbTcdZBumxTUw6UZuir2omRvti/O//Qlm6pdEmxN/3rJt/IIs3VrmXwZBj3quXdYvHItL+POrudDt01BlQ3ewJnZlGHdkepUDfgCWj5HjsrgX/+Qo3LodB9ueU/1Uaog7FCb9Pqhg== X-YMail-OSG: RI92bH8VM1m98qD0FsWhKHpgijgiStsPDuIrqd5GlI7GMu8EIYOdmDi2kI1rTOB 9s8rIxiBFc8e9vW4Iv0yRh0ex.FYGSQ3RZJFb4xVyMjpLdrU3v_lRRUSmW.Mt77kC5nCzkfwW2gm ezNmPrgU0Pm7xJGHBP51dxxA_5.mq0s2lWbY3kBsfv3rN_VttnJTdk0yFMtBou7uEDxuZcONywMz sX2FWIKsfD.mTSDx3tnIyotZ7hl0ri4QlSqvh6X4f3VRarBU8lpypdJmfZjYypcAVCJoXsWqLCYx HLqNbWRuDIypBmFj5nqF84md2ZA8ZB2IYpcd9qfx7EKdZNJoV5WuFDceCSLei0aTrJm.BSklD3xB PUKBQLwna09is91dW9cr35G3tgZaZsTc1PJy86LfQRqP9H4LqjdVF8GjtKyHqzPQu6BMrttdBol6 OWNs3hANokyNamuGTNalW42zt_2aMnpGdeeU8u_a9rKNgZG_iGjbpV57vYgZL512MuWg5kqMzcCj IzY9AibvY0bLNvQ6MyBR36c9tyAQQd5lv7vj1AqYcFmUUALHu.43KvCH9drkRKg_nugctSXJxVdc Rfp9uc3wV3BEcC4S40tE8rsIvgkG.bPYhQenFEavsI542l5F_v9aAT5NI3kuFZBn4T3IWw38ytpf ELhgTLA1vXIPvsEEEhWtIhT24kh.QASsuivs00575PGCQ9odCP9DQjNxFX9s_h1yFh79ITa4s8RO TCwwIic_BlFYzGrvRFrl9GMaerhuWwS8d56y6tEzpx54Ft9_qYQ1jmS5XJ65B1liqYmjYrZx.0iH vaY7KYzogrFmOraQxzj2TNV6Nos7CK8QfJx5foW6tLK4wTLQmgag6B7iZZ.0G5E8BcapyYTOoSey qM2ZNMFPB739ATTSrKTL0LEvUkBQLVhmeeqFOS63UFHpQndHfIt9nTEJ1.P.wRyNS0fj2PAExMyf zbnHdJL0ho30igJh8nbPD4TqFjfeTbEll13Fh4eREcErawkD9MhiTyG5N5YW8HsaaZM.Hg7MDGSq KCvdVGhMB9N_E3YrEbrKPfTcjLma_x3MEjTpT_.rhc0FuviO4zNiayxPOgwUykjDGF1H23VOw6bg we_fpMBuN5c5B3nNJtSZ4krFb4I_Yw06.5SN8q8fMo1HqC8Jw7s7zTk0Wg76iUXz2eOOC3dt2zVp bGOBUcom6LGkSUxamrEM9clvAEGIr2Ggl1eSaUWiLVwCw1EsJY9g9j8jzZNF_k7L1Gz9Z4tl5IID PikRmeSc7i5mT7wgIRsq_2uNi5HmrVGVlf3oonJhj7aueEHzGRseZuIbCCgtHzMkzf4m8rncJpkY 69eGnCoddiwJFF3LPdIbchIb_wGIN0oSmAf3RXHwsIFLYx.GxBrTciLT.5obvwZus.fITRGvesmp srm1WmyXqqWqwehK6TT46lYBY3eepJFOpdX2u11wdJEykx48Ep4dRWOXFgVyM6o509d3rlbFIzIu p3PkkB1_g4d1NtJxvjznwHWBHNDhWzTMqxwcQOZSYdhScAIu39bQz0sBlVIU6L4.5C0a8T3m6WRJ KhsmGNaCI3UXc9zvMRyv1b4.Jnw77GKQYMYYPRiTJdh9.QMt9xRtb.F7GusVtgvrKR.ebCYhzNXg GOPLWfqwUIO8ImbHtGdT2X8oQvunIS4U72XIplNvTrgH9OAtfFT2T8sxU7ez15DAqIMXGJ72sVHy 0iNEIaJklzAVipO.cxJ6xFspQhLAl2pLD31gIDI9YizM9LEvgVdXnyxDBGySTIfyGYz3JB2KGTVD m5.t3rsQLjVX9WxNlHB.8no_Mi3hPIQEiLrlLvqU_1BfUe4CIohUbFr7xi93y5nxzf0Qsx2P_HTF ayPPyrql2rJPw3AjGdIyehoxr7xdQbevUKFPNbNjgdZFUcgyxVHxuYELckx4kPsO6RR3DBvL.TeV 6Ap9F7Tt0Tu8e0gHmwMu22n8CltDfPk6MKQZgoL430gvNaQi8kzjBujqqH4TOt0T8jWKxxxrGN81 iZpqxbkJ7JC9R.AvLFLsokOcmMH.ZU_BinavUWX4VJG8oNpC23wMR0ZHOL_jVbt60ilA9zxFaqIa 8x4qFuJsMBlv.oaK8J_6rkHrPdA5TYNJQ1aF5ehM_asJwCtUbo3TTr.PmXIFMAXZ7UXMylPEek.B jrWRTYQeSko73ICZOcqf1pmoE834CRmacfd6N2l7UmrqiF7ySrdIhgyBGN9JEzW524TM7VndfCvh AVR4RZopWRvtnugG5ZlcIzDHwt3n1n39LCq7emKVcEvFxVjB_TpU4YV9CUw7Dswir2X4UTw_LhFK Pag-- X-Sonic-MF: X-Sonic-ID: 1e5ea815-582b-4e22-b6d9-60b45c9d3ce1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 24 Nov 2025 18:34:22 +0000 Received: by hermes--production-gq1-fdb64d996-snhd5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1c065658e9ab1fa7affe6b112b07a761; Mon, 24 Nov 2025 18:34:15 +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: Re: Still seeing Failed assertion: "p[i] == 0" on armv7 buildworld [kib committed git: 72a447d0bc76 that should help] Date: Mon, 24 Nov 2025 10:34:04 -0800 References: <4957be52-e57f-4f5f-9626-d0f706480fe1@FreeBSD.org> <87ldk9f4tt.wl-herbert@gojira.at> <40BEA46A-96CE-46A1-A994-B8470EE0C844@yahoo.com> To: bob prohaska , Adrian Chadd , Carl Shapiro , Ronald Klop , "Herbert J. Skuhra" , "freebsd-arm@freebsd.org" , FreeBSD Current In-Reply-To: <40BEA46A-96CE-46A1-A994-B8470EE0C844@yahoo.com> Message-Id: <06494416-5EEE-469A-BBB5-36CEC1672BC8@yahoo.com> X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.91 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.91)[-0.910]; 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)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; 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]; RCPT_COUNT_SEVEN(0.00)[7]; MID_RHS_MATCH_FROM(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from] X-Rspamd-Queue-Id: 4dFZH91khfz3FxQ Konstantin Belousov wrote on Date: Mon, 24 Nov 2025 18:09:09 UTC : > The branch main has been updated by kib: >=20 > URL: = https://cgit.FreeBSD.org/src/commit/?id=3D72a447d0bc768c7fe8a9c972f710c75a= febd581b >=20 > commit 72a447d0bc768c7fe8a9c972f710c75afebd581b > Author: Konstantin Belousov > AuthorDate: 2025-11-22 20:39:27 +0000 > Commit: Konstantin Belousov > CommitDate: 2025-11-24 18:08:31 +0000 >=20 > vm_object_page_remove(): clear pager even if there is no resident = pages > =20 > Swap pager might still carry the data. > =20 > Debugging help from: mmel > Reviewed by: alc > Sponsored by: The FreeBSD Foundation > MFC after: 1 week > Differential revision: https://reviews.freebsd.org/D53891 > --- > sys/vm/vm_object.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c > index 5b4517d2bf0c..413ba5459e3d 100644 > --- a/sys/vm/vm_object.c > +++ b/sys/vm/vm_object.c > @@ -1988,7 +1988,7 @@ vm_object_page_remove(vm_object_t object, = vm_pindex_t start, vm_pindex_t end, > (options & (OBJPR_CLEANONLY | OBJPR_NOTMAPPED)) =3D=3D = OBJPR_NOTMAPPED, > ("vm_object_page_remove: illegal options for object %p", = object)); > if (object->resident_page_count =3D=3D 0) > - return; > + goto remove_pager; > vm_object_pip_add(object, 1); > vm_page_iter_limit_init(&pages, object, end); > again: > @@ -2061,6 +2061,7 @@ wired: > } > vm_object_pip_wakeup(object); > =20 > +remove_pager: > vm_pager_freespace(object, start, (end =3D=3D 0 ? object->size : = end) - > start); > } There is still some question about which way another test should be in vm_object_coalesce. But the above should be necessary, even if it is not always sufficient to prevent all potential failure types. See https://reviews.freebsd.org/D53891 for the status of what may be a pending additional change. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Nov 24 20:14: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 4dFcVG4PLgz6HmRh for ; Mon, 24 Nov 2025 20:14:14 +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 4dFcVD5SkGz3SJP for ; Mon, 24 Nov 2025 20:14:12 +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 97653 invoked from network); 24 Nov 2025 20:14:11 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by mail.tarsnap.com with SMTP; 24 Nov 2025 20:14:11 -0000 Date: Mon, 24 Nov 2025 12:14:15 -0800 From: Graham Percival To: freebsd-current@freebsd.org, freebsd-git-weekly@tarsnap.com Cc: Colin Percival Subject: FreeBSD Git Weekly 2025-11-17 to 2025-11-23 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.68 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.99)[-0.992]; 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)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[54.86.246.204:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4dFcVD5SkGz3SJP Hi all, I'm happy to announce FreeBSD git weekly for 2025-11-17 -- 2025-11-23: https://freebsd-git-weekly.tarsnap.net/2025-11-17.html It's a list of the 155 commits in that week, split into categories. Highlighted commits: - msun: expose the C23 functions we already support in "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 24 20:22:03 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 4dFcgR6pYSz6Hms7 for ; Mon, 24 Nov 2025 20:22:11 +0000 (UTC) (envelope-from cpetrik@proton.me) Received: from mail-106118.protonmail.ch (mail-106118.protonmail.ch [79.135.106.118]) (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 "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dFcgR0RK6z3Tpf for ; Mon, 24 Nov 2025 20:22:11 +0000 (UTC) (envelope-from cpetrik@proton.me) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=proton.me header.s=protonmail header.b=ecOp1tfS; dmarc=pass (policy=quarantine) header.from=proton.me; spf=pass (mx1.freebsd.org: domain of cpetrik@proton.me designates 79.135.106.118 as permitted sender) smtp.mailfrom=cpetrik@proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1764015727; x=1764274927; bh=0BF6WmX2xBe+t54Cnqs9H2PLSAFoCtpnLOYcwVtWh9M=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=ecOp1tfSPeAYL0qDSv6xtmluvoVnzX7xqiLMgTayC1myqBI2COKavXgMY/ZHHlSGW 1OHzhtqTUDwVWZ0Bsv3Yye1wQCqD8WyHuYDWvuyLU6mRV00b3ibi2p5d9H7B1ldPhr 2BY3nrIAKaLh5qgiZaX7Qhb6pWkajrtaapcP5bkJN1oSSD6nEtVYMZT+bOJ4wNeCuS Ir4UJ8inMIE/F1sE8g3ZuVmLqdj6E8LZc4lFX7RbrQiyFEjzroQPnC3WWS7iS+bi42 8P8lQ53VGAkOr+Jd/q02ArqdDwZskO/mtoLGzbwSBaT7CLAhnqatQrxPVLnjBgWoTX jo5Rt7vAZx0+g== Date: Mon, 24 Nov 2025 20:22:03 +0000 To: "freebsd-current@freebsd.org" From: Chris Petrik Subject: bsdconfig fails to work Message-ID: Feedback-ID: 65007788:user:proton X-Pm-Message-ID: 654eb374bb9552ff47635667d22479d08c4863c9 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; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------4de385594e75886397f0f486309fe372b843638e9516c029fd801b7a66769c97"; charset=utf-8 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-6.00 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[proton.me,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:79.135.106.0/24:c]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[proton.me:s=protonmail]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[proton.me:+]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4dFcgR0RK6z3Tpf This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------4de385594e75886397f0f486309fe372b843638e9516c029fd801b7a66769c97 Content-Type: multipart/mixed;boundary=---------------------e43cb8b877354483ea7298142a773ae0 -----------------------e43cb8b877354483ea7298142a773ae0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hello, After playing with bsdconfig especially bsdconfig packages it fails to run= as it still detects or wants: SQLITE_REPO=3D"/var/db/pkg/repo-FreeBSD.sqlite" when on my system it's: /var/db/pkg/repos/FreeBSD/db according to file: db: SQLite 3.x database, user version 2014 (0x7de), last written using SQL= ite version 3050004, file counter 27, database pages 17209, 1st free page = 45, free pages 1, cookie 0x1f, schema 4, UTF-8, version-valid-for 27 Chris Sent with Proton Mail secure email. -----------------------e43cb8b877354483ea7298142a773ae0 Content-Type: application/pgp-keys; filename="publickey - cpetrik@proton.me - 0xA2DFE284.asc"; name="publickey - cpetrik@proton.me - 0xA2DFE284.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - cpetrik@proton.me - 0xA2DFE284.asc"; name="publickey - cpetrik@proton.me - 0xA2DFE284.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWlJNS2VoWUpLd1lCQkFI YVJ3OEJBUWRBcVgvTDRBaXNYbG1sM0V0d1p2WmZaQjVMNkZOZjRIL28KV08xTUZRTEdQZ2ZOSldO d1pYUnlhV3RBY0hKdmRHOXVMbTFsSUR4amNHVjBjbWxyUUhCeWIzUnZiaTV0ClpUN0NqQVFRRmdv QVBnV0NaUk1LZWdRTENRY0lDWkNkaVhwdjV2WlFhZ01WQ0FvRUZnQUNBUUlaQVFLYgpBd0llQVJZ aEJLTGY0b1JJYXFqRUpiZVNkSjJKZW0vbTlsQnFBQUFzVHdFQTNYTk1lVitzeWVOZWVLdGIKOVVp QURzcWg3TjNZOWZWZUxvOXZEemsvNEw0QS8xNEg3alVUM2tPOHFVekdyMHBUWE5taXBNZHpyQ0Ju CnVwVUdQRFR1QXhFSnpqZ0VaUk1LZWhJS0t3WUJCQUdYVlFFRkFRRUhRQWE1MmFVQ1pxN1JNWHBS alM1OQovR0F0VjhTSW1vcythOW1vallLVUpzY1ZBd0VJQjhKNEJCZ1dDQUFxQllKbEV3cDZDWkNk aVhwdjV2WlEKYWdLYkRCWWhCS0xmNG9SSWFxakVKYmVTZEoySmVtL205bEJxQUFDa2xBRUE4YUI0 b3k4RE1lTDcwR3lqCmJodW9oSTJpMmdETWtPMFFzejIxTlVZdDZHZ0JBTnFUVGJkT1NIYmp3ejZW OVBDUmkxS2RyL2lqOFZuSAowbnNORGl4OTVGb04KPWdIUUoKLS0tLS1FTkQgUEdQIFBVQkxJQyBL RVkgQkxPQ0stLS0tLQo= -----------------------e43cb8b877354483ea7298142a773ae0-- --------4de385594e75886397f0f486309fe372b843638e9516c029fd801b7a66769c97 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmkkvlsJEJ2Jem/m9lBqRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmf4VWwhbc09K7Xk/KIaeWe8+p8m5V9mq3Zq+cLr jCIXNxYhBKLf4oRIaqjEJbeSdJ2Jem/m9lBqAADb5QD+JJsg3dy/YwdBYmiE OU14Vv1QXvvnPYu9KQucvlkjDh0A/0SE1NCxFtgKA+UDSWWlEKm35z8vq8IP +yktcC8pjVYP =NU6o -----END PGP SIGNATURE----- --------4de385594e75886397f0f486309fe372b843638e9516c029fd801b7a66769c97-- From nobody Mon Nov 24 21:11:11 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 4dFdm93pk4z6Hr8l for ; Mon, 24 Nov 2025 21:11:21 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 4dFdm85JPTz3c04 for ; Mon, 24 Nov 2025 21:11:20 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="Rtf/p0o6"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::32d as permitted sender) smtp.mailfrom=grahamperrin@gmail.com Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-477aa218f20so30014865e9.0 for ; Mon, 24 Nov 2025 13:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764018672; x=1764623472; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SNFMfli3fx2xCSCgY4aTKlL9BtSpbgzWrRrk86/Viak=; b=Rtf/p0o6AY3q3QmnfAlxQF5u/boY1/csHBIwqySHGPbNww4OP3gyowR8zoBIxjzqi2 IjA9Kpi5eX6SIeTvgRhS+JtJwGl7OAF1ujJMGLEhqrThZ+zeR12DdBHCY0PquyDfIWGW 0So6XeaaN8eKcKd3XKgPFYspf8Wyx/WXtswTKAQ9e/IBFr0C0Nl9aEgzsEaLyDTREh1v oxYUQU2xBqdTHOLHmUSNOjQMgHvowXd4qSY4rmc5Ndj44xd9cq4413SF9mrH6AyDp0Sz tNV219sk5Iq0MGu8A3wd7+ZY6tAgA5MQuOGvwRLVGsldZXyKP2mmOJhCug552YGt88Zz cuIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764018672; x=1764623472; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SNFMfli3fx2xCSCgY4aTKlL9BtSpbgzWrRrk86/Viak=; b=K+IgsM9qD0RWIJMhI2dx2YMN3Ajurgf1eEP3kN1A+4P1dvLr6pePCU92X+/+uapRR8 6kFohKv1RU0axvbagDUxca7ftZFIzGfZIrH6ZgeeUYC1FCFQrA/IaPOTtN8ZeJeB9NLE iA5Rl0eqwlaDeJr8DD3X+8DEEKlDuR5+hBDe9B0C0h5RQaNx20WQDe1x1UBiulUHwZPd fTAFQUt0dMD1M9c5652h7K5MW6QRx7mLxnLhby9B5mit2JahB1jgahyiNiwEnkzEt8uY 1WaSB4teO3q5bzJy+YYjVmPcnb/3vUoWc0uUOA6zfxq8KMd186OZy5rGeTgXA9j8nV+a IY8A== X-Gm-Message-State: AOJu0YxiC0HeiTTTAvbb2LeDwsV3ip5LBtCrBIpdHHkEh7MMDgDTbt3E zK9eqb8dGdVaNkUF32Y0rv0Im21dejaku+YrE6CpudH/FJI1X4Zuk2VRLgPsJg== X-Gm-Gg: ASbGnct2S1n/NeCL+6Uxxb9VP0BnlmfYk9xET5YQvSHBTx0NpTbDWJQtykEeiDIfR6G E9xUFDtS9f+97qoj4opWIPYzm7SSvSuYoV2qqaIi9cSURl8VllxEs/PCJ2X1YTxhnQgrRmCr9FF q0DUivprqyUWCUJsF9hZFsnCVOzvhDeqQ0w9IVukuE8bYfkUhPLPQt3m9r/vohmOoLRBSu2Qqh5 KF3y7wdBFvYupiqkxsFOkB3MlY/8EmytPUO2KQrluMr9SBl5SoOi0HmRQw4ZQ+CmJy2G0pJMq+T FpBXkpnzdYmvDaiT9tOJ/s3NVDxGUtGw2BeIXmro+faceVICxRi/TgCvOBXiqASRivHNgrotkwT atFdrQkc89DCw0aOOLCei+rlCAip8/GQQBCYLSWEX2/UwYAGT2K9wVtnPtO0RPmE1nHN344Bh4y unNfeQB47qT9mrtv40oS3NEGsnI3SK87/1+qB0FEGlqvQvrkZfP5koMs20 X-Google-Smtp-Source: AGHT+IFT+rJrf4vpGs7Hx6zHTXI6VC31+ximcETrFWLVi0HLw7TRpSF72iGHlNj9huZSxZw3VwL+Sw== X-Received: by 2002:a05:600c:3baa:b0:475:de12:d3b5 with SMTP id 5b1f17b1804b1-477c01ecc7cmr126918555e9.34.1764018672434; Mon, 24 Nov 2025 13:11:12 -0800 (PST) Received: from [192.168.1.4] (host-2-100-171-17.as13285.net. [2.100.171.17]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-477bf1f365fsm215975555e9.8.2025.11.24.13.11.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Nov 2025 13:11:11 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2025 21:11:11 +0000 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: =?UTF-8?Q?287569_=E2=80=93_bsdinstall=3A_restarting_installation=3A?= =?UTF-8?Q?_Error=3A_No_disk=28s=29_present_to_configure_=28was=3A_Some_issu?= =?UTF-8?Q?es_in_the_20251124_16-CURRENT_snapshot=29?= To: freebsd-current@freebsd.org References: From: Graham Perrin Content-Language: en-GB Autocrypt: addr=grahamperrin@gmail.com; keydata= xsFNBGKYt7ABEAClu83dJ3ZKfVgPOk9YKRv0Z+dl2b88+k9R4vwAmElgguYdKE7yhnQNhhWM v9vi6AFrBMc2oJdVHJ2OrXfwpELBFIgiSMEWNsC4e+Z3HtSajcl+pFZsP7ciiSoycj/w3wIV kAZoVGbhyIbNG7fbCEJ8q81TbfsGypV3bRmbZVvGNecBguYiooBtz2Qht1p3itXMkIA6P9pS YDl+6QddZLyUUAjAnFv2QDoYSHLnaDUWw4oONZsB0SKVu8jMIBh4uJZoYEOvdvc9jQQdOpA2 CAgA6ulfm42Ikr9lKBUUCtjqiWAhJ7iXOTyHAIdR4Mf8alCE6tdTq6dHdIt+GktTY7oYNyL2 3aD3C7I5waU0SFXvJcOMG10QLfwYQMOQoYQ9XJ0U5A28WYiDcylDdUWT7SappP1e1ZMeJWWO y14mxxNzHaJSI4rK8P/p5tp3Q7SSC4k5gMh9zKba3K2ApCWNbVLGvXsJeQkZZNvu70tE81ey AHI5iZcB6D7WaHysBUmsKaEpbcmm1ZThTnGL0SHEl5to5Jab5Fg6O+Cnly5sVz5lX/v8Aosx kKNei7SCVqXOVtteQeGxWbXWbhPgbMyc0Gi3DuxBI/yvJ43k/rJysQlLGLWfJx/UXprwLluC PDK9EvKEB+fD1Z349uzp1sKr3ihpySbyKI8fpudftnAz4EsoCwARAQABzSZHcmFoYW0gUGVy cmluIDxncmFoYW1wZXJyaW5AZ21haWwuY29tPsLBlAQTAQoAPhYhBFk/5bLDBwftvJcvCrdn SG9KGNQLBQJoRALAAhsDBQkPEg5ABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAAAoJELdnSG9K GNQL8YkP/2V1z6XQDyG1QlKAu8TuE8zDWy9QQKjC/G44hlu5zk+2kWSNk4zeExs9ZXOBmVhF EW1d+1J8wDiYIeKYj/rqMoP+gb8o0Au0lSRitvTdLxkZBFGMn0CEzlDOzv+wmiy0ggAV/s+Y EbiHk12fI0LoTy5/ywdmG/uGS7M6p3XOrM0YO1qmLXy1cUyYDsYIpq5/rT0QzpGowsJLoEA3 zz1vfKVY+RTorsL4W8ljXLmcs4c3b3HZG9Xmgtt+Ni/eb9CjzM7kCXOcSMnVzvfscCowPAwB 0ZHlNxNV0MTa61xgvOCk4Zf278ArRgbTm4oOz9Z4ciPMnVue+9P/VdxIxgUuYkAryM0+agGz L9bd8ljn+efNtgZ5dlDLrNnTE+vWnMVlMXgl7BNnhwHg7UYFLrC2xklsICub0qpnNheTGeqo 0N4UongJTQJ6H6LEpgd+KMkCncAHghED/G0/BUdO90VEOoqnIKwKa+F9NqVMvHWc8D58mwCP FghsmxK9FM9pnsjLmG7u+s51Y7++GSRnU4NkI4tHiVk7hcAcvZuc0QbUDwVMTurDUgIqRo6W 80j1tFjEspkrwtMoeVFEkDHktjoc3AoEymXIncZfqIqi3nVseyDVyNByvkV0mutX9hXqac0/ RXMuyK9KniAUZ9+gsWs4rPs/DOdsw4K8/RnjduBrfCYQzsFNBGKYt7ABEADRb1tZuh7DPYET 0wK6fe7owbYgM+RfKhmcrGgR2HI9M2q6+0WKF/ITnggWdIW2Ecc4z2boLz/cwvPGCS7/YxZM 61KklGCwuS7q1s04XnHDWHuFxfXQPzAdVmNO3bYoMZbJjHXs6sB2u5ksiwPwaMAWWaGkviSj c5pwvHCiTmX5vH5CBj/Vi+5ESyX38vK4JM5S/m4ouI/6M9biyFgimV+v3vVyCxJCT1gI9g4o GIh1qq5S433b1fihn4yHPf8XOKyBpA/QcwLONViBqJL5nnOxpsh344rNxn2R7CcRzzicOV+e 2IbMem4lwNWQlZKoRotKXZi9LqN5mynSBYqAUdoZum0QinWT9F22B0Qex5PH1zAt9i2W91Vd kcPB3LwkRXj07ycRtsSzpgPA6fLc6AsoWFslHl8kVOO5eJIA4xhjlPa+W8lguQHZ0iX+5uAv 2eAgXR2swADuHPuENNFStmsgAMl8OOOgtq75yA5TpyIzxMuXV9Nmp0VfIaUM/IdLdmxhc1pC c320l5fYMHVLFAReWEbSj2QH8YzWfpXHIegutWWYEbH9SiDXgS9KoKmCJV/Qa+x6/b8y3pOZ vnIbCDaynC2Yr50s8gRa9kb54JE8Z+p8r16U3SEsK3PtUi0RF0e51danCVHrrE6/Hat2XUO/ 6nnYgVgFOrLao6Gh/VMs8wARAQABwsF8BBgBCgAmFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsF AmhEAsACGwwFCQ8SDkAACgkQt2dIb0oY1AvQxw//REWYFK2m4yS/QP5kzfhkWcNqDI/akGT5 /LXmdmbc1s78+mOMXnA4vBY/+X1QatgxWUECkPDOiIwXJMxoBuyY8e7spLRXeyhtfh5aYaJc MO5bARX0c49v+KfZ80u9tG2rkKQvAt/ySo7OXsbDADFFRhlc8RLbb8e7bSctGbYZk9CYa0ya dW5+n3znDNJ6yW1skx9wTH+Y8VlSazRLk3XgXscNqBA2h56v3WS/R5dI++7AQxZxSQacQvfj 9eahq7ATdB4zMQ9MBHEwOvGD3DLlc55FYSDZvNX+mhnK7S0t1Nt2EtGUOmXb5ysMFGnbsce0 woKQ0sLPF1HWDAAf7tBCF8mpPIzU/ViAkupsJ6NYCD0tLFD8pvl0NYU2TjvyWh6ie3e5B/b3 8Daiyme+M92ivfoRQOFKmkPfeT14AI6OW1k7qFbmoIwMWWQdFWAl1CP9hNdF9gRN4rFB0Jy1 90BajZW2zOdVfqdurJZegCzAowZalLm4JEK2MklpPzipibnJqhLOmvJy587pF52KDdM/4rLy BBREIm7uRivnO5k/BY5qS+H/aqv97LC0PVaTsLXbDmTxTnJplUpdlYT9NGidM+x/ioS0iztO Cht7cT8V8jvvKZYvNpst8iqxuIaoV9V7aZ0wAQpkgDGXHmSzwtz6U8xNf/4e4sLn9KPlldSd kvo= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; FREEFALL_USER(0.00)[grahamperrin]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32d:from] X-Rspamd-Queue-Id: 4dFdm85JPTz3c04 On 24/11/2025 16:00, Tom Jones wrote: > 3. the installer isn't restartable > > In some cases if there has been any error I'll get a message dialog asking if I want to restart the installer because an error occured. The only solution is to reboot and try again. > > If I have created a zfs pool from the installer, the zfs install step can't see any available disks and I have to restart. > > … Hi, that sounds like bug 287569. Skip to comment 4, (Comment 3 is part of a workaround that does not require a reboot.) From nobody Tue Nov 25 03:05: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 4dFncY31j7z6HLXL for ; Tue, 25 Nov 2025 03:05:17 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dFncY2FGkz3QGK; Tue, 25 Nov 2025 03:05:17 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764039917; 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=TcWUEkUnae9/7PWyI/uk0vGqgGN3n0pxXYgbjcBSNMo=; b=mB4h070khOZE2cbIB7L2HW8OSlx0jfpxQpPe3n3ErG8W16Oi53hSMkf1nUlz28qONR18Hh 6GJInEda3i2kcdnB5VzEFGAxPvrc66+M1uDxqIVEohQ+yiMJ6osY0581yiV0VLFZs7GKT+ /A8rG4okU3mQuXDYRoESzJOwc+wqlJlwO334DfTB1GIsflaqitGTpaCUsYyvH3eH6uVqCf EkPZ34aY+05F5Ql8GqVdG4jym7VelQeOuYLeqeYV+Cmy+pvXKO++v89Bzk4ttqPG4fcurx Q3OTotqaZZ7U5lk/LiWO7qvrdH0/5rmBVQxePKLOCAha/uMHOOj63aem/TNWWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764039917; 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=TcWUEkUnae9/7PWyI/uk0vGqgGN3n0pxXYgbjcBSNMo=; b=DTrt4QunejSc0P9IknaAswyVqhMODygrUFZFphouK3m3ztw25M5ON526yedIbN9sZGqmjc a3nhemnohz69+zxy4ybjRYNCQl/mTw7xlQPNm8nl5gowgr+yjZiU5bGA6qqCFotPI90ZKb gz2fCdnSJ0sYorEpm4QZ/Q4JQjO4z4IemaXIKc65H5FdKn9vFNqTrFFpIjDtndv/FXfZUX QWmkKktS8v8fmIiM8uT78t79nVyZLzClYKvzbm0mPu9GETYO728JRF40I7Oqh2QiNMxWd8 6FrCtlOqaBs7jkMs8xgTnbOLqWnb9zAkBpWKgFrTqMkO24vVwL2bLS2XsgEx8Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764039917; a=rsa-sha256; cv=none; b=b5H/hTA3fKLNfz+LTcVrOhrZNZVAuVT0oLrfqTzvMoMvAugamriBNdqjV6bXQvHLtRaWzT Fe/bstjkOwTGceDu7px4da+b18e/G8sIaYDpm+YF1EFQDvquW0gxJvQeNuFwFt6VWlkZro l5zfW6wDgDhzg/718DUs51KCunrGpsGYWR0kXsIJO+pLKbX5HqPCWtLpXEuLB7DEgIaGjZ 7hffjxuRTGkokfhUnM3aCp3YUjSgdnUvrdyz/faYl46NYll+KUi+zC3KoS5JEL9MtBTsE9 z5vU7Kul+ZHCt4rVv19eXbqwvJDZE+maWW1pRBNKsaZpdC4NV31uEvYQHZkcSw== 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 4dFncY0mr0z18p6; Tue, 25 Nov 2025 03:05:16 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 832668E1A5; Tue, 25 Nov 2025 04:05:15 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Chris Petrik Cc: "freebsd-current@freebsd.org" Subject: Re: bsdconfig fails to work In-Reply-To: (Chris Petrik's message of "Mon, 24 Nov 2025 20:22:03 +0000") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 25 Nov 2025 04:05:15 +0100 Message-ID: <86pl967qxg.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Chris Petrik writes: > After playing with bsdconfig especially bsdconfig packages Unfortunately bsdconfig is unmaintained. The last time anyone touched the packages UI was over two years ago. And looking at the code, it wouldn't work correctly in 15 or 16 even if you fixed SQLITE_REPO. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Tue Nov 25 13:52:06 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 4dG3z33qm7z6JBQ2 for ; Tue, 25 Nov 2025 13:52:15 +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 4dG3z21Wklz3LT5 for ; Tue, 25 Nov 2025 13:52:13 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=cVVcF3pp; 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 (crmpreview2.colo2.realworks.nl [10.2.52.32]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4dG3yt2RmMz1Cm for ; Tue, 25 Nov 2025 14:52:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1764078726; 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=m4tvgE6W8m7FA0ThCczJfyGGNEcwm4LPvp3dbaTKLPk=; b=cVVcF3ppiE6TpEVxtg8EnDOa0hcFWLeKOi6KPEYgH6sMnou09Tk4BEsRfiUUvLZ44LbMbW QSD6r9wLNYUHH7gAxogix3CXnmickYSQ2Zl1sMu5Jdcl1KK+lBIYpg4Ay7PqY5TkXXZ30p BQgsQSQM2S9IZu0UnsZfD5mngPS6QeKo4CCWD9gHvLxOfq+iSy3Y1mHaUIZjzICOMEUpJ5 Itrt95RK0bMx3n2hCieZtfj7gV6uqQFg6vAgBYmhpO+6QWYlrAsAuefZuJEZ6NNi2HWkq4 O3VnkQFFD6UhSY0xICQQsPiADi/eEnhMlURT6hGv54P6Jo7zFoRTk9yZYpuv7w== Received: from crmpreview2.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview2.colo2.realworks.nl (Postfix) with ESMTP id 52B6F26020F for ; Tue, 25 Nov 2025 14:52:06 +0100 (CET) Date: Tue, 25 Nov 2025 14:52:06 +0100 (CET) From: Ronald Klop To: current@freebsd.org Message-ID: <1375923085.6629.1764078726226@localhost> Subject: building libclang and WITHOUT_TOOLCHAIN? 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_6628_565370350.1764078725958" X-Mailer: Realworks (774.21) X-Originating-Host: from (83-81-212-149.cable.dynamic.v4.ziggo.nl [83.81.212.149]) by crmpreview2.colo2.realworks.nl [10.2.52.32] with HTTP; Tue, 25 Nov 2025 14:52:06 +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 [-2.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; 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_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[klop.ws:+] X-Rspamd-Queue-Id: 4dG3z21Wklz3LT5 ------=_Part_6628_565370350.1764078725958 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, My build setup contains WITHOUT_TOOLCHAIN which saved me a lot of time on the Raspberry Pi's. Since a while they are building llvm/clang stuff nonetheless. I have the feeling this started when llvm/clang started to be build as private libraries. https://github.com/freebsd/freebsd-src/commit/2e47f35be5dc61945afdbd1a70e8fd505c032c94 Could this change have influenced how WITHOUT_TOOLCHAIN works? Would it be possible to skip building these libraries using other knobs? Or is my thought about this unfounded? Regards, Ronald. ------=_Part_6628_565370350.1764078725958 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

My build setup contains WITHOUT_TOOLCHAIN which saved me a lot of time on the Raspberry Pi's.
Since a while they are building llvm/clang stuff nonetheless.
I have the feeling this started when llvm/clang started to be build as private libraries.

https://github.com/freebsd/freebsd-src/commit/2e47f35be5dc61945afdbd1a70e8fd505c032c94

Could this change have influenced how WITHOUT_TOOLCHAIN works?
Would it be possible to skip building these libraries using other knobs?

Or is my thought about this unfounded?

Regards,
Ronald.

  ------=_Part_6628_565370350.1764078725958-- From nobody Tue Nov 25 14:27:47 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 4dG4mR1Rb6z6JF49 for ; Tue, 25 Nov 2025 14:28:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 4dG4mQ6295z3S79 for ; Tue, 25 Nov 2025 14:28:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-3418ac74bffso3720710a91.1 for ; Tue, 25 Nov 2025 06:28:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1764080880; x=1764685680; 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=4wlZMhr59PO0Dimi/RpZBZ21gcrKWsJM6TNCpt6Rj9E=; b=j97hOcjvhtfBmN1t9b6R/JqApTHknzgzeBBpZffLpbp7el6LhSP7iD8Ev5dnpcK9Hf 9ZTZOsbLqKu5HjKOdmPhna7gHsmA2SFwZBs2O5L8l8bk13hfIbJtCb57t0eRl4iy4nYf ImGD2XZuIrmTCm4s/l46+NekWnfl6EHM0/R05SVKAZjjESi1x3ZxTr6BuYAbLMpplA+W Fcmt5MWlmyvZgOdYyU6lLhlACgngqBKBrD9n0VYcC3wspUOA07zc8vx4uOCE8dro8/TD 6AWiCKVx6msqrEibBlBt7vWo9wjQNLRYLUfuCPerULLlrKYBFB/BipYeQtgO81IQIudN ZEqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764080880; x=1764685680; 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=4wlZMhr59PO0Dimi/RpZBZ21gcrKWsJM6TNCpt6Rj9E=; b=qcHewtzQ+ZCyQJRX5E/PtXsdGgaW1XgcFu5d/ySb88mRQmQpV68WRX3HGaDHHw35qv u8t2OBOwS0edbS+B7QlODI6nKqN9mMI139Pb0oU3LY5kEprjjmUw88aL9mEAfeVq7QCJ hJ7cfInxCdqCKsL1LrNMEPQN2ecLkg1bGyHb6NKzC8tm2vF8EmIAYG+NuMJH8r3IILxm ji7JTOgGXgCM6OWQRs+IXKPFG9F8hyi3+Rhv7ezNE+1hzcGBsTB3k5tAIdcJYUzuPzFA YvHMLbuDoUsFEDipkZjWpMhHXkJfr2SSIdfFxxHz50sA2ShhIGiLXDFcfuQ1IEnrmhUq ye4Q== X-Gm-Message-State: AOJu0YyKNJIWZT0jtEd+gXC8riYzIQa1kKoHW6Xy1kw3zxZXPmFDx35T +w/eldOrizAXwwAG2plk2FLeNblX1oWsLWGPYogiC/wpHkP0e9Dqp1mnl7tls5k8Xougg+OxzPx m5YDYWXEPuRnpzG4yyg3UfX9hIbHnrLY10mzKSmpbYhJ63Oz9aVJH X-Gm-Gg: ASbGncsT3t4+RMbPz0xWE3j1uD4VfRvtZHipCUU/0Z2YkJlJb6htDXGsxZyI+6D6R8i tCxfmKfy6sa+JCDQRz915NqY43wsjVdDqWKvHyYcFq3HSJHbiKUbpfiIYKEpKv0Ox+T5WIb6CRT /hgqSUp1Kt/NQd7uIJ+M46vUgu9UcVedVaCQPRwxlZy5HsHDNie0UpZteIbwVKRJ943fbYIqQzJ M5syUSdeC2Twcjz/cq+mEhMzvElZDVsZdE+lztpy7ggvNDitwMWFNNA4ZY6BbrkmemEYWZXIQBe VRdNDpXCSM/xwA== X-Google-Smtp-Source: AGHT+IFPR/OJc+NLXWNilGAAYpgP1TTjx/T8jVDAgNhZyFspVpNVqzqaONhwU7izVJc/Scyp1oEk8I0fiYpVQmkcGTE= X-Received: by 2002:a17:90b:1c0e:b0:340:b152:efe7 with SMTP id 98e67ed59e1d1-3475ebfa34amr3204969a91.11.1764080879147; Tue, 25 Nov 2025 06:27:59 -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: <1375923085.6629.1764078726226@localhost> In-Reply-To: <1375923085.6629.1764078726226@localhost> From: Warner Losh Date: Tue, 25 Nov 2025 07:27:47 -0700 X-Gm-Features: AWmQ_bkBJamvVlz2dOJdppuhL7rW80KeMRmbUoRNVlk2NlbPHKJIokCyEjRmVv4 Message-ID: Subject: Re: building libclang and WITHOUT_TOOLCHAIN? To: Ronald Klop Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000282e0d06446c1687" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dG4mQ6295z3S79 --000000000000282e0d06446c1687 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 25, 2025, 6:52=E2=80=AFAM Ronald Klop wr= ote: > Hi, > > My build setup contains WITHOUT_TOOLCHAIN which saved me a lot of time on > the Raspberry Pi's. > Since a while they are building llvm/clang stuff nonetheless. > I have the feeling this started when llvm/clang started to be build as > private libraries. > > > https://github.com/freebsd/freebsd-src/commit/2e47f35be5dc61945afdbd1a70e= 8fd505c032c94 > > Could this change have influenced how WITHOUT_TOOLCHAIN works? > Would it be possible to skip building these libraries using other knobs? > > Or is my thought about this unfounded? > In yhr last week or three i fixed a bug in metamode that eould always rebuild the toolchain... when did you last try? Warner Regards, > Ronald. > > > --000000000000282e0d06446c1687 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 25, 2025, 6:52=E2=80= =AFAM Ronald Klop <ronald-lists@= klop.ws> wrote:
Hi,

My build setup contains WITHOUT_TOOLCHAIN which saved me a lot of time on t= he Raspberry Pi's.
Since a while they are building llvm/clang stuff nonetheless.
I have the feeling this started when llvm/clang started to be build as priv= ate libraries.

https://github= .com/freebsd/freebsd-src/commit/2e47f35be5dc61945afdbd1a70e8fd505c032c94

Could this change have influenced how WITHOUT_TOOLCHAIN works?
Would it be possible to skip building these libraries using other knobs?
Or is my thought about this unfounded?


=

Regards,
Ronald.

=C2=A0
--000000000000282e0d06446c1687-- From nobody Tue Nov 25 15:12:10 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 4dG5lL0BZhz6JJ1s for ; Tue, 25 Nov 2025 15:12:14 +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 4dG5lK3rbJz3ZNk for ; Tue, 25 Nov 2025 15:12:13 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmpreview5.colo2.realworks.nl [10.2.52.35]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4dG5lH3cZzz1Wm; Tue, 25 Nov 2025 16:12:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1764083531; 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=mCRIN869CSlcEKMYsoVdooCffZpvBwIThYXiOCuYnqM=; b=LIws5aLFB+JtfP9+yTwnbdioz8YsbCvgEzRnzdjHKu3ptURDYL71RmDcg++BzT3E0zgxWk Kv07bC8ATKonfo44Awf+KeKmDDd8pz+0pmofbYFtJB0vovQzHpYKVhsoDbQGQb49UG2JNh T4UX1jgCkeElrZXCTLrYqYBGr75C/l95GMPGVtWs8UpgYp+EED6xmwkV50b9+uwtq9b2pw JXAKu6THaaRuwrazy571drszfvuIBHkq7Sx5KG5mDcvJam/ryjtyngZGWKIBBTLiEC1VEt sE2vWHfDDwwfjbm9+yKVBaAFzA30E4x0cATsgOVxofjgGfdnCBsvqcUVQCKUfA== Received: from crmpreview5.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview5.colo2.realworks.nl (Postfix) with ESMTP id 5D7CDC02F2; Tue, 25 Nov 2025 16:12:10 +0100 (CET) Date: Tue, 25 Nov 2025 16:12:10 +0100 (CET) From: Ronald Klop To: Warner Losh Cc: FreeBSD Current Message-ID: <1085097762.8654.1764083530992@localhost> In-Reply-To: References: <1375923085.6629.1764078726226@localhost> Subject: Re: building libclang and WITHOUT_TOOLCHAIN? 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_8653_1932903303.1764083530983" X-Mailer: Realworks (774.21) X-Originating-Host: from (83-81-212-149.cable.dynamic.v4.ziggo.nl [83.81.212.149]) by crmpreview5.colo2.realworks.nl [10.2.52.35] with HTTP; Tue, 25 Nov 2025 16:12:10 +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 [-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: 4dG5lK3rbJz3ZNk ------=_Part_8653_1932903303.1764083530983 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Warner Losh Datum: dinsdag, 25 november 2025 15:27 Aan: Ronald Klop CC: FreeBSD Current Onderwerp: Re: building libclang and WITHOUT_TOOLCHAIN? > > > On Tue, Nov 25, 2025, 6:52AM Ronald Klop wrote: >> >> Hi, >> >> My build setup contains WITHOUT_TOOLCHAIN which saved me a lot of time on the Raspberry Pi's. >> Since a while they are building llvm/clang stuff nonetheless. >> I have the feeling this started when llvm/clang started to be build as private libraries. >> >> https://github.com/freebsd/freebsd-src/commit/2e47f35be5dc61945afdbd1a70e8fd505c032c94 >> >> Could this change have influenced how WITHOUT_TOOLCHAIN works? >> Would it be possible to skip building these libraries using other knobs? >> >> Or is my thought about this unfounded? > > > In yhr last week or three i fixed a bug in metamode that eould always rebuild the toolchain... when did you last try? > > Warner > >> >> Regards, >> Ronald. >> >> > Currently building 16-current on a 15 days old system. I don't think I use metamode. I just do buildworld. $ uname -a FreeBSD rpi5 16.0-CURRENT FreeBSD 16.0-CURRENT #2 main-n281790-abd53b16c03f: Mon Nov 10 23:34:05 CET 2025 root@rpi5:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG arm64 $ ps d -D down -p 7025 PID TT STAT TIME COMMAND 7025 1 I+ 0:00.00 /usr/local/bin/bash /home/ronald/bin/makeworld.sh 7058 1 IN+ 0:00.00 - time make -j4 -DWITHOUT_CLEAN=yes -DWITHOUT_TOOLCHAIN=yes buildworld 7059 1 SN+ 0:01.79 `-- make -j4 -DWITHOUT_CLEAN=yes -DWITHOUT_TOOLCHAIN=yes buildworld 7095 1 IN 0:00.00 `-- sh -ev 7096 1 SN 0:01.86 `-- make -m /usr/src/share/mk -f Makefile.inc1 TARGET=arm64 TARGET_ARCH=aarch64 buildworld 21526 1 IN 0:00.00 `-- sh -ev 21527 1 IN 0:00.00 `-- time env MACHINE_ARCH=aarch64 MACHINE=arm64 CPUTYPE= CC=cc -target aarch64-unknown-freebsd16.0 --sysroot=/u 21528 1 SN 0:01.62 `-- make -f Makefile.inc1 BWPHASE=libraries DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp -DNO_FSCHG MK_HTML=no 21554 1 IN 0:00.00 `-- sh -ev 42314 1 SN 0:00.53 `-- make -f Makefile.inc1 _generic_libs 42323 1 IN 0:00.00 `-- sh -ev 42327 1 SN 0:00.51 `-- make MK_TESTS=no DIRPRFX=lib/ all 48783 1 IN 0:00.00 `-- sh -e 48784 1 SN 0:00.04 `-- make all DIRPRFX=lib/clang/ 48787 1 IN 0:00.00 `-- sh -e 48788 1 SN 0:08.68 `-- make all DIRPRFX=lib/clang/libllvm/ 54507 1 SN 0:00.00 |-- sh -ev 54508 1 RN 0:14.53 | `-- c++ -target aarch64-unknown-freebsd16.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 54518 1 SN 0:00.00 |-- sh -ev 54519 1 RN 0:06.47 | `-- c++ -target aarch64-unknown-freebsd16.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 54524 1 SN 0:00.00 |-- sh -ev 54525 1 RN 0:01.34 | `-- c++ -target aarch64-unknown-freebsd16.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 54526 1 SN 0:00.00 `-- sh -ev 54527 1 RN 0:00.68 `-- c++ -target aarch64-unknown-freebsd16.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp Regards, Ronald. ------=_Part_8653_1932903303.1764083530983 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Warner Losh <imp@bsdimp.com>
Datum: dinsdag, 25 november 2025 15:27
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: FreeBSD Current <current@freebsd.org>
Onderwerp: Re: building libclang and WITHOUT_TOOLCHAIN?

 
In yhr last week or three i fixed a bug in metamode that eould always rebuild the toolchain... when did you last try?
 
Warner
 
Regards,
Ronald.

 


Currently building 16-current on a 15 days old system. I don't think I use metamode. I just do buildworld. 
$ uname -a
FreeBSD rpi5 16.0-CURRENT FreeBSD 16.0-CURRENT #2 main-n281790-abd53b16c03f: Mon Nov 10 23:34:05 CET 2025     root@rpi5:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG arm64

$ ps d -D down -p 7025
  PID TT  STAT    TIME COMMAND
 7025  1  I+   0:00.00 /usr/local/bin/bash /home/ronald/bin/makeworld.sh
 7058  1  IN+  0:00.00 - time make -j4 -DWITHOUT_CLEAN=yes -DWITHOUT_TOOLCHAIN=yes buildworld
 7059  1  SN+  0:01.79 `-- make -j4 -DWITHOUT_CLEAN=yes -DWITHOUT_TOOLCHAIN=yes buildworld
 7095  1  IN   0:00.00   `-- sh -ev
 7096  1  SN   0:01.86     `-- make -m /usr/src/share/mk -f Makefile.inc1 TARGET=arm64 TARGET_ARCH=aarch64 buildworld
21526  1  IN   0:00.00       `-- sh -ev
21527  1  IN   0:00.00         `-- time env MACHINE_ARCH=aarch64 MACHINE=arm64 CPUTYPE= CC=cc -target aarch64-unknown-freebsd16.0 --sysroot=/u
21528  1  SN   0:01.62           `-- make -f Makefile.inc1 BWPHASE=libraries DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp -DNO_FSCHG MK_HTML=no
21554  1  IN   0:00.00             `-- sh -ev
42314  1  SN   0:00.53               `-- make -f Makefile.inc1 _generic_libs
42323  1  IN   0:00.00                 `-- sh -ev
42327  1  SN   0:00.51                   `-- make MK_TESTS=no DIRPRFX=lib/ all
48783  1  IN   0:00.00                     `-- sh -e
48784  1  SN   0:00.04                       `-- make all DIRPRFX=lib/clang/
48787  1  IN   0:00.00                         `-- sh -e
48788  1  SN   0:08.68                           `-- make all DIRPRFX=lib/clang/libllvm/
54507  1  SN   0:00.00                             |-- sh -ev
54508  1  RN   0:14.53                             | `-- c++ -target aarch64-unknown-freebsd16.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
54518  1  SN   0:00.00                             |-- sh -ev
54519  1  RN   0:06.47                             | `-- c++ -target aarch64-unknown-freebsd16.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
54524  1  SN   0:00.00                             |-- sh -ev
54525  1  RN   0:01.34                             | `-- c++ -target aarch64-unknown-freebsd16.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
54526  1  SN   0:00.00                             `-- sh -ev
54527  1  RN   0:00.68                               `-- c++ -target aarch64-unknown-freebsd16.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp


Regards,
Ronald.
  ------=_Part_8653_1932903303.1764083530983-- From nobody Tue Nov 25 22:58: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 4dGJ684tMHz6Hx4s for ; Tue, 25 Nov 2025 22:59:12 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (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 4dGJ675RsHz3fvw for ; Tue, 25 Nov 2025 22:59:11 +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.46 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-948da744f87so224647239f.1 for ; Tue, 25 Nov 2025 14:59:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764111550; x=1764716350; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qSrjv4ybd3Awl51dsBD1/L/wsCJHcaZOPoi/EFDv3J4=; b=Osdj0Dq1PwHSkR3GCZiZQZYwLGppW0jl2rdvexR80SIGFGucCQsfECENPiCCbvOjP3 zDCQsGbqKALIL3dGApAQucZwduNvT2eKttwPrU7CoR7b1y2mZsFS2a71Xf+HAunP9mHp 0LPDJx17F2S0IzMeRypTNYEmX0fC3WpyQEljRZ2/PFeglMbM3vj+tYfZbrhJ4qZ0A05S TUx6gDGQkOCOxFaX1nFE6v54ocO8NMOBq0XfvcksQ6uKMbpRBV17ZIJb4Oc1dh4ieLWN 2I9mDDxlK6jzIap70CoE6qmstk34yqa+5wSs3jOAXk5JjnTivpaQu0OXWXlkKL281/AQ 6gMQ== X-Gm-Message-State: AOJu0YyNbYONdGxL0EHbSAM81Fo/U2kwCmHPvdnXnkWxgDo37QYP2Vk+ MTTuKtZ3E+VfjSzkXfeUqEPbVPrhn/azAi9V/msubC9zEjTjQl8uqNKJnD8WJuYIUG1cDSQURkJ bJ0P5Cv5bmWAdGBbejEyNgcTwY1ATbha+RRJe X-Gm-Gg: ASbGncvcxLRTgdnh1Ki9qJ+eEFYRiQZTz6Dwv+q3uNIwXoZgcdCaxyM57ZhCg82Yvqi /yreDeBeHIgJqD8pn+N7KuSeAExIuAnidGfCi3dfOkioyQo9bGyczxgN329BWG77n9/IWxPjNpG EhTCh8dB7eAWMuQHipxhji33h3U05qQv++Ma4HFR/VcdsThoh2cRkl1xElmT5c0N1knIbCez/li +YWSWgOESsjiLdvwpnG48KnpRBRVAy3WJnzuxrAvctDhalPcE8DZjaHhwcCBW/05A4GfaygUt+/ 2vf2acuv6CYP4w5y+JZltDYzg44= X-Google-Smtp-Source: AGHT+IH3gVfypPUrSnlWBUyCZs16soFvVbvX76olS0giFrFj5nskWR1BfzPa6rWvlUQ2P4/siCsc+ksPFzgmHLru6i8= X-Received: by 2002:a05:6638:ad56:b0:5b7:c4b0:a183 with SMTP id 8926c6da1cb9f-5b9993ec8a4mr2863572173.0.1764111550273; Tue, 25 Nov 2025 14:59:10 -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 From: Ed Maste Date: Tue, 25 Nov 2025 17:58:59 -0500 X-Gm-Features: AWmQ_blNgb5C9LaZXFbvHVTusgVlgVSGh8C1j2US16bno4xz-LicmTHqCVF3bUc Message-ID: Subject: Request for testing [was: Heads-up: Kernel module symbol resolution changing] To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: - X-Spamd-Result: default: False [-1.32 / 15.00]; NEURAL_HAM_MEDIUM(-0.86)[-0.863]; NEURAL_HAM_LONG(-0.33)[-0.330]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; NEURAL_HAM_SHORT(-0.22)[-0.224]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.46:from]; TO_DOM_EQ_FROM_DOM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.46:from] X-Rspamd-Queue-Id: 4dGJ675RsHz3fvw On Wed, 12 Mar 2025 at 13:07, Ed Maste wrote: > > Our in-kernel module linker currently performs symbol resolution > against local symbols from other modules, which is a bug. > > In commits 95c20faf11a1 and ecd8245e0d77 kib introduced support to > have the kernel linker stop resolving local symbols from other files, > but did not change it by default to avoid surprises. The > debug.link_elf_leak_locals sysctl controls this behaviour, currently > defaulting to resolving against local symbols (1). Setting it to 0 > turns this off. > > I plan to flip the default soon, in advance of FreeBSD 15.0. See > PR207898 and https://reviews.freebsd.org/D47742 for more information. This did not happen for 15.0, but should for 16.0. I flipped the default earlier today but reverted again after reports of module load failures and because it's currently stabweek. I hope to commit it again next week, and need some help identifying and resolving potential issues before doing so. A failure will show up on the system console (and in dmesg, /var/log/messages) as something like: link_elf_obj: symbol kern_kmq_open undefined linker_load_file: /boot/kernel/linux.ko - unsupported file type I'm aware of two failures so far: 1. i915kms.ko, on a system with agp built as a module PR291214, fixed by a87c1e2dd8fc 2. linux.ko (presumably) due to kern_kmq_* symbols Fix in review: https://reviews.freebsd.org/D53907 There is also a possible issue with x11/nvidia-driver, but it may not be related. Investigation is ongoing in PR291212. I would appreciate it if folks can test other modules. To do so, add the following lines to /boot/loader.conf and reboot: debug.link_elf_leak_locals=0 debug.link_elf_obj_leak_locals=0 If any module starts failing to load (with "symbol ____ undefined" console messages) please open a PR with the details. Then remove the loader.conf lines and carry on as before. From nobody Tue Nov 25 23:31: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 4dGJqM2r4Qz6Hyvp for ; Tue, 25 Nov 2025 23:31:27 +0000 (UTC) (envelope-from olivier@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 4dGJqM29qGz3lRg for ; Tue, 25 Nov 2025 23:31:27 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764113487; 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=vy1s6924+EvC3ZYrisdfY3FVBYvPOlwcxkhgyfZiw9I=; b=U+3v9bMaIK6BjWjKq8NE6m70ZMCxsPyHzAaWZAiYAkILsahJeEuNwMTSFEyMAygHJOIcUk zulmVm3Y5hZR1XcvSaVddtFfQb+zuskScJmSCHfM6hjVR6Q4g5XX6BPN200+eXnHcViXca 5iNQqIFmsiZ1Y0EzCNm92rwOpU+CWvde3mK2nb5cEfW5SVHSKWzj2pMlIxw684FT59PShR 16+EhbQ3028quQUspn1VeMnlr2236OK6x8lAcT368AwYiZytgdBqeKZ2MucNr8kIT5rBrq P/d9NV+qlFdu6Ofn9ew4xQNbmfSG73ob77nr2FLAb/UzTYx3uLhoXaMVewXB0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764113487; 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=vy1s6924+EvC3ZYrisdfY3FVBYvPOlwcxkhgyfZiw9I=; b=lisG1UVZ5UvEkXkoEWtkjqnawF7sd1+QHC1ZKXgvD/Sh1tflVn5X58f9n6/xdeczB77eGw krqHR3WPl8xMOI6fAYMdsYVfH+r3hJb2TXHaGUd4hBy6Osgs9poTFJfzRkV8l9M/OTdZ7w GoxHR0nfS9+xJUJz+HoyEgDZx30r8vo9dz1FfuWhERtivwe9JiFLblz89EvKFKZ6Zcggyh Ma0yGAwxZHVbLfgLQWLoMufxtuTXvqPD/L1jWlzruYoA0F1xP0W02l8JQl6feI5t/zrpBJ l70u/D4rtLa2GD2LAzGj2k6OB7LH/8Q3PQF9qWab7Fo1QqgztWHPCl2ywt0nqQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764113487; a=rsa-sha256; cv=none; b=P0ZJZtPdi8/Q1orYSjWeesRNTJLDGLt/VnCnSamkqrS7+UKJkrVXGKwn+ea9qtqguBtOII M9PVOvhtcp0FCHegFAXo9LWznu9I/9eXErJ2qMhLTOiuuIzit4mZoBFYFDEwSRwxx9o9gG jLZVz5hZ6gv9YUX2+8eqkhw4lbxpGR3MOD7X4WCvClUSvj1qhuBCujAhewtS94FtN5SnqA 8HXIPmLaAY5TIX3S0icArVUAmqucLPu9bvPc2N+SBhTX/ECnbi2FoV7a78MZ1cb6oTP7TN 8vfVD9OoDe/RYzHjye2gDEPH0Wr/LulArWKsERxhmEmQzmAlScCQcZeGK4VNfA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (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)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dGJqM1SVDzMdm for ; Tue, 25 Nov 2025 23:31:27 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-4ee05b2b1beso53641101cf.2 for ; Tue, 25 Nov 2025 15:31:27 -0800 (PST) X-Gm-Message-State: AOJu0YxV+Ydl6K8C/5fdlXKFeTvKTDvGoq68CCv26i0fXAY8YkIMM6ub P2c3dbnJhbqoOxpAK78sWeHMt92CkQa0njK15KgXIXe7HNZQZ11LYDo009onY/Mll69cYL/4OZc dFmzDwjw7YjM8NkKGX8+oykQa89rKNpY= X-Google-Smtp-Source: AGHT+IFDVvH9z/+dCg5NUYn0hrJtznlVwYXwbDtYIWapKALX2DF2O0pLI891Cb5Tmft37nVpArFsDJtIXL1HMzAMe3I= X-Received: by 2002:a05:622a:1193:b0:4ee:9b1:e2c with SMTP id d75a77b69052e-4ee5885ff55mr234479191cf.33.1764113486694; Tue, 25 Nov 2025 15:31:26 -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: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Wed, 26 Nov 2025 00:31:15 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bkg_0tabEokUmymLxOyGOVNGWMhCk39dvqOe4QclVgqI-e3axc3mgT6LMw Message-ID: Subject: Re: November 2025 stabilization week To: freebsd-current@freebsd.org, src-committers@freebsd.org Cc: Gleb Smirnoff Content-Type: multipart/alternative; boundary="000000000000b7cfad064473ad76" --000000000000b7cfad064473ad76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, This is an update on the current November 2025 stabilization week on our Netflix A/B test deployment. We had one significant finding: dhw@ noticed a regression (higher system CPU utilization), which was quickly troubleshooted by gallatin@, patched by chs@, and pushed by imp@. This was excellent teamwork! The fix is in the following commit: "git: 2b4dbad2db57 - main - nda: fix setting of unmappedio flag" On my end, my personal build machine, Workstation, NAS, and laptop have all been upgraded, and I have not observed any further regressions. Separately, reading the -current mailing list, thj@ reported an issue with the 20251124 16-CURRENT snapshot, which appears to be very close to the stabweek state. You can view the report here: https://lists.freebsd.org/archives/freebsd-current/2025-November/009491.htm= l I will keep the stabilization window open for one more day to allow for any final reports before officially closing the stabweek. Regards, Olivier On Mon, Nov 24, 2025 at 10:00=E2=80=AFAM Gleb Smirnoff wrote: > Hi FreeBSD/main users & developers: > > This is an automated email to inform you that the November 2025 > stabilization week > started with FreeBSD/main at main-n282109-a067eb525e10, which was tagged = as > main-stabweek-2025-Nov. > > Those who want to participate in the stabilization week are encouraged to > update to the above revision/tag and test their systems. > > The tag main-stabweek-2025-Nov has been published at Gleb Smirnoff's > github repo. > To connect this repo as an additional remote you need to run: > > git remote add glebius https://github.com/glebius/FreeBSD > > Once remote is configured, to checkout the tag run: > > git fetch glebius --tags > git checkout main-stabweek-2025-Nov > > If you want to use only the official FreeBSD repo, then update to > the revision: > > git pull > git checkout a067eb525e10 > > Developers are encouraged to avoid pushing new features to FreeBSD/main > during > the stabilization week, but focus on bugfixes instead. The stabilization > week > runs up to Friday 18:00 UTC, but if there is consensus that any regressio= ns > discovered by participants have been fixed, it will end early. > > Once that happens, the advisory freeze of FreeBSD/main branch is thawed. > > -- > Gleb Smirnoff > > --000000000000b7cfad064473ad76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,
This is an update on the current November 2025 stabilization week on our = Netflix A/B test deployment.
We had one significant finding:
dhw@ not= iced a regression (higher system CPU utilization), which was quickly troubl= eshooted by gallatin@, patched by chs@, and pushed by imp@. This was excell= ent teamwork!
The fix is in the following commit:
"git: 2b4dbad2= db57 - main - nda: fix setting of unmappedio flag"

On my end, m= y personal build machine, Workstation, NAS, and laptop have all been upgrad= ed, and I have not observed any further regressions.

Separately, rea= ding the -current mailing list, thj@ reported an issue with the 20251124 16= -CURRENT snapshot, which appears to be very close to the stabweek state. Yo= u can view the report here: https://lists.freebsd.org/archive= s/freebsd-current/2025-November/009491.html

I will keep the stab= ilization window open for one more day to allow for any final reports befor= e officially closing the stabweek.

Regards,

Olivier

On M= on, Nov 24, 2025 at 10:00=E2=80=AFAM Gleb Smirnoff <glebius@freebsd.org> wrote:
=
=C2=A0 Hi FreeBSD/m= ain users & developers:

This is an automated email to inform you that the November 2025 stabilizati= on week
started with FreeBSD/main at main-n282109-a067eb525e10, which was tagged as=
main-stabweek-2025-Nov.

Those who want to participate in the stabilization week are encouraged to update to the above revision/tag and test their systems.

The tag main-stabweek-2025-Nov has been published at Gleb Smirnoff's gi= thub repo.
To connect this repo as an additional remote you need to run:

=C2=A0 git remote add glebius https://github.com/glebius/FreeBSD

Once remote is configured, to checkout the tag run:

=C2=A0 git fetch glebius --tags
=C2=A0 git checkout main-stabweek-2025-Nov

If you want to use only the official FreeBSD repo, then update to
the revision:

=C2=A0 git pull
=C2=A0 git checkout a067eb525e10

Developers are encouraged to avoid pushing new features to FreeBSD/main dur= ing
the stabilization week, but focus on bugfixes instead.=C2=A0 The stabilizat= ion week
runs up to Friday 18:00 UTC, but if there is consensus that any regressions=
discovered by participants have been fixed, it will end early.

Once that happens, the advisory freeze of FreeBSD/main branch is thawed.
--
Gleb Smirnoff

--000000000000b7cfad064473ad76-- From nobody Wed Nov 26 04:03: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 4dGQs05Tssz6JKcx for ; Wed, 26 Nov 2025 04:03:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0: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 4dGQs00bGBz3N1b for ; Wed, 26 Nov 2025 04:03:16 +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=T373u0tQ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::62e) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-2980d9b7df5so76979685ad.3 for ; Tue, 25 Nov 2025 20:03:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1764129794; x=1764734594; 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=hz5IBK6V0ZlbyRcuMUoRnaJ/RNj1E/p8+heZ27iqNT8=; b=T373u0tQwpYk+4VYeb5ml5njwIp1X+KQx9KxzZYboN1Ksa9lKoII9c1s55Xi0leYZ4 ICwCPdpbrseUBOglN1DVZAEhjaOFzkAJnrwl1qc5sVqKI4tSQ7Z44B9W7nHn8kLhgCAw eFNxgrzuSeuTiHo8AmAMTqJpzd2jO1goN9Q5FRhgXbVynT1ALyhuWaa/GkN1KV5G2qCp vBw26z96nWXP3T0bhJ566sox8RCpzyNxF9vFsG+zIffhuPU8j8WhagXdFbVJqzsCDtr2 HsklYuF+NyNFVl7V3brXbFy14ZEKuX5+XEmAK/PCx6PQsc7Srz/B+Mm4GOTR1b+9m6JG 4+2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764129794; x=1764734594; 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=hz5IBK6V0ZlbyRcuMUoRnaJ/RNj1E/p8+heZ27iqNT8=; b=kggSC3VnBizSlH36HnUpzKJFX/l4Z7rEgIwMoyxfDzU6EYjufIOgEKycXHVrL5CPot 4HbpP1zVNUpWgqPT1qsqEQ/aPF+ot7LzHoOx5elCTA8J0WKWrqEZnP0kWeyEKxOBxbU+ XulxCh88/ZehNiScJogaHVrUE9BrFuWl+NXKcfflPvNLvJWIWI/v2DGbRNM0mJvTcah5 Bf/dTd8iUU2VdBdT3l2X3vCFGl8wUrtxNjxeRvtDKOjIQyWDR9kwE216pjr9kFvLG2p8 9/t66VhbNC165z2OO2e5iqnIxKOzBg9ymG7uF3hHB15HFwJLL0iHNqV394ZBSPRjohZQ NuUw== X-Gm-Message-State: AOJu0YxuQ9FGRDnlt1BB5ARvIN61xt2KVL6KzPsrE7aqCkIklNbtjbef dD5V7rijcIFENxZCdm6Nq7xFP2AHt+Ai8colSluy6uSb3pOIoCjwAr6I1cYRhT3i8Fo1Nn7XxJl zghgOgr+pOWp6ckyqpW/lEFGGQKi++2G6ZLAvpANFvP97dWAs2S/awvA= X-Gm-Gg: ASbGncsRT+iCqi7ZMlyBPjeD9/ipBYwuJagzeEBaQb4O2311feWuPyWIfGH8cIBELgi 0I5ZylyuVtkQZdon2PLGvgLc5YJkI27pgvOTtl+LZ/lYFqMT7vWkVkxjkLcae6tPH9luX5Yzh+Q qqcQYj+jUDDDkO8T7a2lS0uXPNqhRNMHt8V/GUvO/tpbtwxk+0mtZyj0A0AUoipfeYbW4qhoIdd V5hbEF/zWYt3+HN7iVvq8u3msa8BUeKIvKc0+P+JYhy2/VNuu2vaPEJIDOsMlZjhYguhGw= X-Google-Smtp-Source: AGHT+IGrXwODx505I4gVCZv0LkWMeD4yp51bLRYIOEjKsZkFQxq8GTc8s0ovwjiRpSbPYBHI2shEx6jPgSmEQHkFNx0= X-Received: by 2002:a17:903:1b50:b0:295:8da5:c631 with SMTP id d9443c01a7336-29b6bf65833mr215151085ad.42.1764129793697; Tue, 25 Nov 2025 20:03:13 -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: <20251123151439.361dd84c@thor.sb211.local> In-Reply-To: <20251123151439.361dd84c@thor.sb211.local> From: Warner Losh Date: Tue, 25 Nov 2025 21:03:01 -0700 X-Gm-Features: AWmQ_bl3jp4YUgld0M5cRa5eSx2z5jS4FH5fPCrmOSk8Ka4ZdSqtSI7DWC_tquk Message-ID: Subject: Re: freezing on unmountin ext2fs USB device To: A FreeBSD User Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000b0fa170644777995" X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; 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]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::62e:from]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4dGQs00bGBz3N1b --000000000000b0fa170644777995 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 23, 2025 at 7:15=E2=80=AFAM A FreeBSD User wrote: > Hello, > > running FreeBSD 16.0-CURRENT #4 master-n282101-c8cf5a99f82b: Sun Nov 23 > 13:56:23 CET > 2025 amd64 I'm running into a serious problem when mounting an ext2fs > formated USB Flash > device (512GB). The devince contains files written by a Linux system, > mounting the USB Flash > via extended4fs, the size of the written datafiles is > 128GB. Deleting > those files larger > than some 20GB results in an I/O error reported by FReeBSD (# sudo rm > /mnt/USB/filename). > Unmounting the ext2fs after deletion (sudo umount /mnt) results in a tota= l > freeze of the box. > No crash, no core dump, nothing. I waited almost an hour hoping for > recover. I have to > physically switch off the box. > > I checked with other USB flash I have at hand, one Samsung 256 GB, ZFS - > no problem, another > 128GB, UFS, no problem and several much smaller (4 - 64GB) with FAT or UF= S > filesystems, all no > problem. > > I can not figure out whether it is the USB flash drive itself, the size o= r > the ext2fs itself > causing the problem. > > Does anybody see similar problems or do have an tip to investigate withou= t > risking my box' > health switching it on/off on failure? > I've not seen this on the smaller tests I've been able to run. So can you share the error messages that you get when you say you get I/O errors? I'd like to see if this is due to an error in ext2fs or on the USB drive. It's kinda sounding a little like the particular USB is triggering some kind of issue that at the very least we should work around. Given that it's not happening on all ext2fs drives you try to access, I'm leaning towards the drive, but you never know. Thanks --000000000000b0fa170644777995 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Nov 23,= 2025 at 7:15=E2=80=AFAM A FreeBSD User <freebsd@walstatt-de.de> wrote:
Hello,

running FreeBSD 16.0-CURRENT #4 master-n282101-c8cf5a99f82b: Sun Nov 23 13:= 56:23 CET
2025 amd64 I'm running into a serious problem when mounting an ext2fs f= ormated USB Flash
device (512GB). The devince contains files written by a Linux system, mount= ing the USB Flash
via extended4fs, the size of the written datafiles is > 128GB. Deleting = those files larger
than some 20GB results in an I/O error reported by FReeBSD (# sudo rm /mnt/= USB/filename).
Unmounting the ext2fs after deletion (sudo umount /mnt) results in a total = freeze of the box.
No crash, no core dump, nothing. I waited almost an hour hoping for recover= . I have to
physically switch off the box.

I checked with other USB flash I have at hand, one Samsung 256 GB, ZFS - no= problem, another
128GB, UFS, no problem and several much smaller (4 - 64GB) with FAT or UFS = filesystems, all no
problem.

I can not figure out whether it is the USB flash drive itself, the size or = the ext2fs itself
causing the problem.

Does anybody see similar problems or do have an tip to investigate without = risking my box'
health switching it on/off on failure?

= I've not seen this on the smaller tests I've been able to run.

So can you share the error messages that you get=C2=A0= when you say you get I/O errors? I'd like to see if this is due to an e= rror in ext2fs or on the USB drive. It's kinda sounding a little like t= he particular USB is triggering some kind of issue that at the very least w= e should work around. Given that it's not happening on all ext2fs drive= s you try to access, I'm leaning towards the drive, but you never know.=

Thanks
--000000000000b0fa170644777995-- From nobody Wed Nov 26 07:31: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 4dGWTF6rkHz6HcMP for ; Wed, 26 Nov 2025 07:31:29 +0000 (UTC) (envelope-from olivier@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 4dGWTF57w1z3gWN for ; Wed, 26 Nov 2025 07:31:29 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764142289; 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=L3chZ8rb/TfOyViDgjyAxoorN2jGmPR1TBWPqpivGBI=; b=mLn9WyU9YrxUoKAcRaF7B3ZVM2kAMKzmcS5miOKL33LXFj7JKwMSMUpH5MahiqQH2CIPMx 7niJv8VRzdFfydL8olQQMsvZ1SVkeUrgferZhxcDKvdz3IPK2OLcMUvO70zIbufhFJ+xtG 7SWb22DPz69m9kWnBmZXfMRque8neqCHocl3Cz27IjS6jk1czcdJ6MfKBnIf84pP1zVwri 15DpfJS/+4FvJ6at3z3EgfP/f1/hQjPsOcPk9CfXJk+UvnOTbMceI1k/jmWOqC52W91n8/ P9QderAo0dnupL3IoTKU2wE+EaDhzT+WJGqcdmu6YLL+I7ZBJ1E8GUMe97SGFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764142289; 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=L3chZ8rb/TfOyViDgjyAxoorN2jGmPR1TBWPqpivGBI=; b=NC3QB8t3bnvnW6At9NfQBi+nOd0a/V8+jNko2zOJwRQMR6vu5eTHQP3bjmMtSy7NlZVXxw 7+0OiSy3fWyJQWRUBmJKzbZD1nVLKz76uM+7HmJPtezgY5s9Feo9s7t85oFqXA+d91cypv B6r8wwZAYWTie8WItnL6kOg6myuVd5b3FSVeJouFnkv08t7fWRbmpDmZyuuNKk+56mlHf9 BFfG3OBAwVuqK/JuldVTtcgXz4lQWETq4xGqEp73sBy8x1ByEJqwKKFEWuqXT9isAiIo59 NwUP63kHSKKePccVdwYWSOEidCtDcabr66Y3m8fd2Kx9pUt1X61iggMRjBPL4g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764142289; a=rsa-sha256; cv=none; b=FPlpvT76CTB7m22fkyU8Uvw+GkLzN522ZtM61LeNEjpBUvGuytuuBUyMk2exOHIpACdIMS U84T+bWrfC7Wsas14ZwOGtVLeL5m7g3iKUq6Nqk/XoRTshyTOBTD3w/Wu/RQR2tfObe8LP pVQLmj9oHImTJlFdOFPYIl3HFQT9cWLbLnDOiSVLI09n2Bx30OhrtHGV6A4nraWUtAFcqf bSxTm81EgJNM+n6KlZPE8xHTdS0o9Y8ACnBBDRLf1tgDBLbhTRHqvu+BQfGZAuReRpHHrU eVhdmSTkI9o4lAYb8gcHvQGd67orlb0wmHL3vz0pOmGPKkY2D8TJWQbZjGYADg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) (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)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dGWTF4B0DzmD7 for ; Wed, 26 Nov 2025 07:31:29 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-882399d60baso52711696d6.0 for ; Tue, 25 Nov 2025 23:31:29 -0800 (PST) X-Gm-Message-State: AOJu0YwTP9TJMpcxw4F/kyR567ct789ZQDPcAxgZ6gfoTWoOBU3D8C6J VHH3NoAlJnoMQVqQ0lv545el9x3BlnETCqeAgb/jPXffzQpLORoZQLtngsDi9VhLgH4Y7KbYIE9 /sR5z7UW+qTWGTTmZPgc8Xk7qkGfpQik= X-Google-Smtp-Source: AGHT+IG1tWa2L0zSE4bfEaAL1RFVpiYXXgzs+BPjg9Sw3+hcj1QocNKwshxDXJUoYMoxS5z2GGILuCcpMywpAttWAEU= X-Received: by 2002:a05:6214:5297:b0:87b:b3a2:6727 with SMTP id 6a1803df08f44-8863af9e784mr84221376d6.45.1764142289080; Tue, 25 Nov 2025 23:31:29 -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: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Wed, 26 Nov 2025 08:31:17 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bnvmosb1kK6khHNXDLP5P5PS5BbD_SGeJkqDMO79w1ELybTcMVmbtdPXuM Message-ID: Subject: Re: November 2025 stabilization week To: freebsd-current@freebsd.org, src-committers@freebsd.org Cc: Gleb Smirnoff Content-Type: multipart/alternative; boundary="000000000000795bb906447a6250" --000000000000795bb906447a6250 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, There is a critical regression related to the zfsbootcfg/bectl utility. The issue was encountered when attempting to upgrade one of our clusters that was already running a Nov 2025 stabweek. The bug prevents successful activation of a new boot environment via bectl activate -t xxx. Given that this regression actively prevents system upgrades and new deployments, it appears to be a serious blocker. The issue match this Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D291211 Regards, Olivier On Wed, Nov 26, 2025 at 12:31=E2=80=AFAM Olivier Cochard-Labb=C3=A9 wrote: > Hello everyone, > > This is an update on the current November 2025 stabilization week on our > Netflix A/B test deployment. > We had one significant finding: > dhw@ noticed a regression (higher system CPU utilization), which was > quickly troubleshooted by gallatin@, patched by chs@, and pushed by imp@. > This was excellent teamwork! > The fix is in the following commit: > "git: 2b4dbad2db57 - main - nda: fix setting of unmappedio flag" > > On my end, my personal build machine, Workstation, NAS, and laptop have > all been upgraded, and I have not observed any further regressions. > > Separately, reading the -current mailing list, thj@ reported an issue > with the 20251124 16-CURRENT snapshot, which appears to be very close to > the stabweek state. You can view the report here: > https://lists.freebsd.org/archives/freebsd-current/2025-November/009491.h= tml > > I will keep the stabilization window open for one more day to allow for > any final reports before officially closing the stabweek. > > Regards, > > Olivier > > On Mon, Nov 24, 2025 at 10:00=E2=80=AFAM Gleb Smirnoff > wrote: > >> Hi FreeBSD/main users & developers: >> >> This is an automated email to inform you that the November 2025 >> stabilization week >> started with FreeBSD/main at main-n282109-a067eb525e10, which was tagged >> as >> main-stabweek-2025-Nov. >> >> Those who want to participate in the stabilization week are encouraged t= o >> update to the above revision/tag and test their systems. >> >> The tag main-stabweek-2025-Nov has been published at Gleb Smirnoff's >> github repo. >> To connect this repo as an additional remote you need to run: >> >> git remote add glebius https://github.com/glebius/FreeBSD >> >> Once remote is configured, to checkout the tag run: >> >> git fetch glebius --tags >> git checkout main-stabweek-2025-Nov >> >> If you want to use only the official FreeBSD repo, then update to >> the revision: >> >> git pull >> git checkout a067eb525e10 >> >> Developers are encouraged to avoid pushing new features to FreeBSD/main >> during >> the stabilization week, but focus on bugfixes instead. The stabilizatio= n >> week >> runs up to Friday 18:00 UTC, but if there is consensus that any >> regressions >> discovered by participants have been fixed, it will end early. >> >> Once that happens, the advisory freeze of FreeBSD/main branch is thawed. >> >> -- >> Gleb Smirnoff >> >> --000000000000795bb906447a6250 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

There is= a critical regression related to the zfsbootcfg/bectl utility.

The = issue was encountered when attempting to upgrade one of our clusters that w= as already running a Nov 2025 stabweek. The bug prevents successful activat= ion of a new boot environment via bectl activate -t xxx.

Given that = this regression actively prevents system upgrades and new deployments, it a= ppears to be a serious blocker.

The issue match this Bugzilla:
https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D291211

Regards,
Olivier

On Wed, Nov 26, 2025 at 12:= 31=E2=80=AFAM Olivier Cochard-Labb=C3=A9 <olivier@freebsd.org> wrote:
Hello everyone,
This is an update on the current November 2025 stabilization week on = our Netflix A/B test deployment.
We had one significant finding:
dhw@= noticed a regression (higher system CPU utilization), which was quickly tr= oubleshooted by gallatin@, patched by chs@, and pushed by imp@. This was ex= cellent teamwork!
The fix is in the following commit:
"git: 2b4d= bad2db57 - main - nda: fix setting of unmappedio flag"

On my en= d, my personal build machine, Workstation, NAS, and laptop have all been up= graded, and I have not observed any further regressions.

Separately,= reading the -current mailing list, thj@ reported an issue with the 2025112= 4 16-CURRENT snapshot, which appears to be very close to the stabweek state= . You can view the report here: https://lis= ts.freebsd.org/archives/freebsd-current/2025-November/009491.html
I will keep the stabilization window open for one more day to allow for a= ny final reports before officially closing the stabweek.

Regards,
Olivier

On Mon, Nov 24, 2025 at 10:00=E2=80=AFAM Gleb Smirnoff &l= t;glebius@freebsd.= org> wrote:
=C2=A0 Hi FreeBSD/main users & developers:

This is an automated email to inform you that the November 2025 stabilizati= on week
started with FreeBSD/main at main-n282109-a067eb525e10, which was tagged as=
main-stabweek-2025-Nov.

Those who want to participate in the stabilization week are encouraged to update to the above revision/tag and test their systems.

The tag main-stabweek-2025-Nov has been published at Gleb Smirnoff's gi= thub repo.
To connect this repo as an additional remote you need to run:

=C2=A0 git remote add glebius https://github.com/glebius/FreeBSD

Once remote is configured, to checkout the tag run:

=C2=A0 git fetch glebius --tags
=C2=A0 git checkout main-stabweek-2025-Nov

If you want to use only the official FreeBSD repo, then update to
the revision:

=C2=A0 git pull
=C2=A0 git checkout a067eb525e10

Developers are encouraged to avoid pushing new features to FreeBSD/main dur= ing
the stabilization week, but focus on bugfixes instead.=C2=A0 The stabilizat= ion week
runs up to Friday 18:00 UTC, but if there is consensus that any regressions=
discovered by participants have been fixed, it will end early.

Once that happens, the advisory freeze of FreeBSD/main branch is thawed.
--
Gleb Smirnoff

--000000000000795bb906447a6250-- From nobody Wed Nov 26 15:37: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 4dGkG573C0z6JDJC; Wed, 26 Nov 2025 15:37:33 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4dGkG44XbDz3RRY; Wed, 26 Nov 2025 15:37:32 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=kZbWh7Uk; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id DD3D52405CB; Wed, 26 Nov 2025 16:37:23 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 561C124003C; Wed, 26 Nov 2025 16:37:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764171442; 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; bh=FCSpEwMld5VsFiQn72+Od48WuaZdGMPRjT/qC02eBSY=; b=kZbWh7UkxJPF8TLsVdkm0l/78o5m3yJ15Mwva/Fge++35S04pDflAH/trwLWAAerXBGoHa 3cmeykkJ4ls0svXsWeiHEkHHyKWmD/qMh3MjM1e7i5xkYxHDaOdgnDW0gVY+VGapwiZzoc tQ+wlunXQH4P6mN6OvLYHZDXz6SOZQEESBOc/MB/0DB1qt9F+8mIoksu6YHcNcuwMwIhsk bGAukuZOsHc0CtXsELA/hBj6fo8QZMnMGSftQRctvT71TjEpotsqoC8pM6lb2W5eIitFPD zXpgJReKXGJ3HRok2r71gnmhnWqyS5GhFWFGWkHi2Bp6TQq4k+KKMlKziTO3mw== Received: from hermann (dynamic-2a02-3100-2903-d302-cb42-cf69-eb1a-f5fe.310.pool.telefonica.de [IPv6:2a02:3100:2903:d302:cb42:cf69:eb1a:f5fe]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 12E1924002F; Wed, 26 Nov 2025 16:37:22 +0100 (CET) Date: Wed, 26 Nov 2025 16:37:21 +0100 From: FreeBSD User To: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: FreeBSD/X11: Howto revive DisplayPort? Message-ID: <20251126163059.3376d3e8@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 6d5996 X-Rspamd-UID: fc90ae X-Spamd-Bar: - X-Spamd-Result: default: False [-1.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-x11@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4dGkG44XbDz3RRY Using FreeBSD CURREN and FreeBSD STABLE/15. Also, most systems are attached to a KVM switch, connected via DP. Hosts booting all UEFI. On hosts using X11/xdm GUI, switching forth and back to the output/host I want to use DP does obviously not "lose" DP output, so after graphics has been initialized I'm able to see the GUI. The situation is completely different with plain consoles, provided by FreeBSD's EFI/UEFI simple framebuffer device driver. Working on the console on one host, switching to another host, working there and trying to switch back leaves me with no output anymore! I see this behaviour with different types of KVM switches I have at hand. Can this behaviour be changed, even with no X11? Thanks in advance and wishes, O. Hartmann From nobody Wed Nov 26 16:11:40 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 4dGl1Z6D3Fz6JGcj for ; Wed, 26 Nov 2025 16:11:46 +0000 (UTC) (envelope-from comdir@infonix.info) Received: from forward102a.mail.yandex.net (forward102a.mail.yandex.net [IPv6:2a02:6b8:c0e:500:1:45:d181:d102]) (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 4dGl1Z0T0Tz3Y7D for ; Wed, 26 Nov 2025 16:11:46 +0000 (UTC) (envelope-from comdir@infonix.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=infonix.info header.s=mail header.b=mrTanvgw; dmarc=none; spf=pass (mx1.freebsd.org: domain of comdir@infonix.info designates 2a02:6b8:c0e:500:1:45:d181:d102 as permitted sender) smtp.mailfrom=comdir@infonix.info Received: from mail-nwsmtp-mxback-production-main-62.iva.yp-c.yandex.net (mail-nwsmtp-mxback-production-main-62.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:bf1c:0:640:6992:0]) by forward102a.mail.yandex.net (Yandex) with ESMTPS id 4BF6AC006E for ; Wed, 26 Nov 2025 19:11:41 +0300 (MSK) Received: from mail.yandex.ru (2a02:6b8:c0c:4dac:0:640:dd72:0 [2a02:6b8:c0c:4dac:0:640:dd72:0]) by mail-nwsmtp-mxback-production-main-62.iva.yp-c.yandex.net (mxback/Yandex) with HTTPS id 7Bg4kA0xu8c0-XSxyH8fw; Wed, 26 Nov 2025 19:11:40 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infonix.info; s=mail; t=1764173500; bh=44cd+/vDfeioSAr4luQvZt+DphNWwPxerRjgrvrOnJg=; h=Message-Id:Date:Subject:To:From; b=mrTanvgwb6WYUOgSi6fpBH/HnGGLNqcC3AEqvYZrq1fwGoKCSlMSjbL+/H5CgHvp2 gPaL67qJkKD67iN16CK6siO/SiiBsm9jo4xjz6bTCdT17YqaktVWOonhBoa/sv6gmd FXcLPK71yFqTRgorH12OuvBThlxCuEoxgNXBQYvE= Received: by ske52ucy55r5y36k.iva.yp-c.yandex.net (sendbernar/Yandex) with HTTPS id f9a170a01a9b96900d6a6c581c48a226; Wed, 26 Nov 2025 19:11:40 +0300 From: =?utf-8?B?0JvQtdC+0L3QuNC0INCT0L3QtdC30LTQuNC70L7Qsg==?= To: "freebsd-current@FreeBSD.org" Subject: operation not supported Wayland 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 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 26 Nov 2025 19:11:40 +0300 Message-Id: <11071764173299@mail.yandex.ru> Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 X-Spamd-Bar: / X-Spamd-Result: default: False [0.51 / 15.00]; NEURAL_HAM_LONG(-0.95)[-0.951]; NEURAL_SPAM_MEDIUM(0.95)[0.946]; NEURAL_SPAM_SHORT(0.71)[0.714]; MIME_HTML_ONLY(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:c00::/40]; R_DKIM_ALLOW(-0.20)[infonix.info:s=mail]; MIME_BASE64_TEXT(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[2a02:6b8:c0e:500:1:45:d181:d102:from]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; MIME_TRACE(0.00)[0:~]; DMARC_NA(0.00)[infonix.info]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_EQ_ADDR_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[infonix.info:+] X-Rspamd-Queue-Id: 4dGl1Z0T0Tz3Y7D PGRpdj48ZGl2PjxkaXYgc3R5bGU9ImJveC1zaXppbmc6Ym9yZGVyLWJveCI+PGRpdiBzdHlsZT0i Ym9yZGVyLXJhZGl1czowcHggM3B4IDNweCAwcHg7Ym94LXNpemluZzpib3JkZXItYm94O21pbi13 aWR0aDowcHg7cGFkZGluZzoxMHB4O3ZlcnRpY2FsLWFsaWduOnRvcDt3aWR0aDoxNDIyLjM5cHgi PjxkaXYgc3R5bGU9ImJveC1zaXppbmc6Ym9yZGVyLWJveDtoZWlnaHQ6MTU2LjU0N3B4Ij48ZGl2 IHN0eWxlPSJib3gtc2l6aW5nOmJvcmRlci1ib3g7bWluLWhlaWdodDoxcHgiPjxkaXYgc3R5bGU9 ImJveC1zaXppbmc6Ym9yZGVyLWJveCI+PGRpdj48ZGl2IHN0eWxlPSJib3gtc2l6aW5nOmJvcmRl ci1ib3giPjxkaXYgc3R5bGU9ImJveC1zaXppbmc6Ym9yZGVyLWJveCI+SGkhPC9kaXY+PGRpdiBz dHlsZT0iYm94LXNpemluZzpib3JkZXItYm94Ij5GcmVlQlNEIDE2LjAtQ1VSUkVOVCwgV2F5bGFu ZC4gQWZ0ZXIgdGhlIG9uZSBvZiB1cGdyYWRlIChvciBhZnRlciBzb21lIG9mIG15IGV4cGVyaW1l bnRzIHdpdGggdGhlIHN5c3RlbSksIG1hbnkgYXBwbGljYXRpb25zIHN0b3BwZWQgcnVubmluZy4g TW9zdCBhcHBsaWNhdGlvbnMuIE9sZCwgcHJvYmFibHkgWFdheWxhbmQsIGFwcGxpY2F0aW9ucyB3 b3JrLiBUZWxlZ3JhbS1kZXNrdG9wLCBhIHJveC10ZXJtaW5hbCwgYnJvd3NlciB3YXMgYWJsZSB0 byBydW4gLSBuZXQtc3VyZi48YnIgc3R5bGU9ImJveC1zaXppbmc6Ym9yZGVyLWJveDttYXJnaW4t dG9wOjBweCIgLz48YnIgc3R5bGU9ImJveC1zaXppbmc6Ym9yZGVyLWJveCIgLz5FcnJvcnMgZHVy aW5nIGxhdW5jaCB2YXJ5LCBidXQgYWxtb3N0IGV2ZXJ5dGhpbmcgaXMgdW5pdGVkIGJ5ICJvcGVy YXRpb24gbm90IHN1cHBvcnRlZCAob3MgZXJyb3IgNDUpIjwvZGl2PjxkaXYgc3R5bGU9ImJveC1z aXppbmc6Ym9yZGVyLWJveCI+V2VsbCwgeWVzLCBXYXlsYW5kIGNvbXBvc2l0b3JzIHN0YXJ0IGFu ZCB3b3JrIHdpdGhvdXQgcHJvYmxlbXMgKGh5cHJsYW5kLCBsYWJ3YywgaGlrYXJpKSwgZXJyb3Jz IG9jY3VyIHdoZW4gbGF1bmNoaW5nIGNvbXBvc2l0b3JzIGNsaWVudHMgLSBhcHBsaWNhdGlvbnMu PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9k aXY+PGRpdj7CoDwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6I2ZmZmZm Zjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6aW5saW5lICFpbXBvcnRhbnQ7ZmxvYXQ6bm9uZTtmb250 LWZhbWlseTptb25vc3BhY2U7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13 ZWlnaHQ6NDAwO3RleHQtYWxpZ246c3RhcnQ7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFj ZTpub3JtYWwiPi0twqA8L3NwYW4+PGJyIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYiggMjU1 ICwgMjU1ICwgMjU1ICk7Y29sb3I6cmdiKCAxMDIgLCAxMDIgLCAxMDIgKTtmb250LWZhbWlseTpt b25vc3BhY2U7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6NDAw O3RleHQtYWxpZ246c3RhcnQ7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWwi IC8+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6I2ZmZmZmZjtjb2xvcjojNjY2NjY2O2Zv bnQtZmFtaWx5Om1vbm9zcGFjZTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXdlaWdodDo0MDA7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNw YWNlOm5vd3JhcCI+0KHCoNCj0LLQsNC20LXQvdC40LXQvCw8L3NwYW4+PGJyIHN0eWxlPSJiYWNr Z3JvdW5kLWNvbG9yOnJnYiggMjU1ICwgMjU1ICwgMjU1ICk7Y29sb3I6cmdiKCAxMDIgLCAxMDIg LCAxMDIgKTtmb250LWZhbWlseTptb25vc3BhY2U7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpu b3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtYWxpZ246c3RhcnQ7dGV4dC10cmFuc2Zvcm06bm9u ZTt3aGl0ZS1zcGFjZTpub3JtYWwiIC8+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6I2Zm ZmZmZjtjb2xvcjojNjY2NjY2O2ZvbnQtZmFtaWx5Om1vbm9zcGFjZTtmb250LXNpemU6MTJweDtm b250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LXRy YW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vd3JhcCI+0JvQtdC+0L3QuNC0wqDQk9C90LXQt9C0 0LjQu9C+0LI8L3NwYW4+PGJyIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYiggMjU1ICwgMjU1 ICwgMjU1ICk7Y29sb3I6cmdiKCAxMDIgLCAxMDIgLCAxMDIgKTtmb250LWZhbWlseTptb25vc3Bh Y2U7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQt YWxpZ246c3RhcnQ7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWwiIC8+PHNw YW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6I2ZmZmZmZjtjb2xvcjojNjY2NjY2O2ZvbnQtZmFt aWx5Om1vbm9zcGFjZTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdo dDo0MDA7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5v d3JhcCI+0J7QntCewqAi0JjQndCk0J7QndCY0JrQoSI8L3NwYW4+PGJyIHN0eWxlPSJiYWNrZ3Jv dW5kLWNvbG9yOnJnYiggMjU1ICwgMjU1ICwgMjU1ICk7Y29sb3I6cmdiKCAxMDIgLCAxMDIgLCAx MDIgKTtmb250LWZhbWlseTptb25vc3BhY2U7Zm9udC1zaXplOjEycHg7Zm9udC1zdHlsZTpub3Jt YWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtYWxpZ246c3RhcnQ7dGV4dC10cmFuc2Zvcm06bm9uZTt3 aGl0ZS1zcGFjZTpub3JtYWwiIC8+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6I2ZmZmZm Zjtjb2xvcjojNjY2NjY2O2ZvbnQtZmFtaWx5Om1vbm9zcGFjZTtmb250LXNpemU6MTJweDtmb250 LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LXRyYW5z Zm9ybTpub25lO3doaXRlLXNwYWNlOm5vd3JhcCI+KzcoNDcxMik3NzAtMzY1PC9zcGFuPjxiciBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2IoIDI1NSAsIDI1NSAsIDI1NSApO2NvbG9yOnJnYigg MTAyICwgMTAyICwgMTAyICk7Zm9udC1mYW1pbHk6bW9ub3NwYWNlO2ZvbnQtc2l6ZToxMnB4O2Zv bnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0OjQwMDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtdHJh bnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsIiAvPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiNmZmZmZmY7Y29sb3I6IzY2NjY2Njtmb250LWZhbWlseTptb25vc3BhY2U7Zm9udC1z aXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtYWxpZ246c3Rh cnQ7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3dyYXAiPis3KDkxOSkyMTAtOTct NzM8L3NwYW4+PC9kaXY+PGRpdj7CoDwvZGl2Pg== From nobody Wed Nov 26 16:31: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 4dGlSJ3XrVz6JHkW for ; Wed, 26 Nov 2025 16:31:28 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) (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 4dGlSJ1dg2z3cgd for ; Wed, 26 Nov 2025 16:31:28 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-787df0d729dso69477017b3.3 for ; Wed, 26 Nov 2025 08:31:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764174687; x=1764779487; 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=yHVo6iw3ZIAJ+gMREtg0/i4d3nRvJbmQofy90Cz9js0=; b=KUEoWQwlwAy9gpRF1+Ee9LEN6/WFkLb7cS+//R9hFO/dia8oaO7hfGnlKfOsVcsVCd tvWmhwvj3F8SoD7qgMymnSGCa8HOaUbtQx6+U3zKtlO/Va4qFNawROykkRxsko3pw50i uETLs/JrO1RH1Vb9SU1MXpNDjoBkpXTzKsMJ8/eysgcnGOacO4D6k5F4ag5AKKOkcmFE ai4lp1C4mL8Nix/GP3+UAnqQ/H9AVjeWMEwlQ15+HKVRD3TjKPx9y6OGF9m+EJYKHhiH gAomnB95OMBKtEHF+tOW8rORY4QHmjNGIuTXalLGZNsE+WuD+DZOTKIhcvovSw4b4U26 u0Ug== X-Gm-Message-State: AOJu0Yw0B6GIfwoEcLCLknhrpnv7W0vNLlU5wAlF6Vbhk2IjwHqrVrP0 pGfwNkVonOJbgvnTBdimS43q/6x5ksYL4lwOBfBO8CIvkex7DFMc7tMrEmH9TA== X-Gm-Gg: ASbGnctd7G58baugDd5glfbnsSl1VYDLbDEFqafx84HwF9opYwBwX88tTuuviCQWVyy +4JKFWfhujqdAqFQsw6DnQhAEzHc/M2ebVBP9+3N+IH6W+bSDSvinNKjLCYclFDUYcqWlU8D/jC TrJmK7yYTibIdHA67tTOzJNMeHgVNXNVqet2ey4MV/zauVomK5uaVvdPwh3usWk06IVr8zbeCN+ jQX/XrdaO2WHIFeIXeOIxgOPqUA9uk5IoeGCEw8U56kXC+prlA2JpgPtkMut9gqcaJn4Zed0IyE ENJzRae9peqoSr7sscJuV6cm2oMpQO5L47/nMuqB0w7gtnq2uSMH9uksIFYZtjkVKBYnKfQWXZy KlvHzcJ68Pcrto4n4duYYTF/cs773K123Ie9iJhHipBzUNovIDKdfT6vPAWJMV/2wRVFN5Gp1Ad M2snVqlnKutXZMf/kuaarhxupV4IImjbrP/A5OJjKF9Me8OtmZMHe96ytQ9ZKj X-Google-Smtp-Source: AGHT+IENfvjmq6HH9FmfhovfshOmK08QSlEqaYUplHYHBYRNE5YVw3RSBkhv0vGZIDZQl1LDLsKsmg== X-Received: by 2002:a05:690c:6901:b0:787:d13f:4b49 with SMTP id 00721157ae682-78a8b478e34mr174618747b3.12.1764174687190; Wed, 26 Nov 2025 08:31:27 -0800 (PST) Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com. [209.85.128.172]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78a7987f5e4sm68202897b3.8.2025.11.26.08.31.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Nov 2025 08:31:26 -0800 (PST) Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-7866bca6765so61158447b3.1 for ; Wed, 26 Nov 2025 08:31:26 -0800 (PST) X-Received: by 2002:a05:690c:6f0d:b0:786:8172:e21 with SMTP id 00721157ae682-78a8b54e042mr174680187b3.56.1764174686614; Wed, 26 Nov 2025 08:31:26 -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: <11071764173299@mail.yandex.ru> In-Reply-To: <11071764173299@mail.yandex.ru> From: Gleb Popov Date: Wed, 26 Nov 2025 19:31:00 +0300 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bkRX6meD6lbjqmqQ-cqw1vuygyqFXzhCp6f7liUf2e1HZton-4AnNBnYiI Message-ID: Subject: Re: operation not supported Wayland To: =?UTF-8?B?0JvQtdC+0L3QuNC0INCT0L3QtdC30LTQuNC70L7Qsg==?= Cc: "freebsd-current@FreeBSD.org" 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)[]; 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: 4dGlSJ1dg2z3cgd On Wed, Nov 26, 2025 at 7:12=E2=80=AFPM =D0=9B=D0=B5=D0=BE=D0=BD=D0=B8=D0= =B4 =D0=93=D0=BD=D0=B5=D0=B7=D0=B4=D0=B8=D0=BB=D0=BE=D0=B2 wrote: > > Hi! > FreeBSD 16.0-CURRENT, Wayland. After the one of upgrade (or after some of= my experiments with the system), many applications stopped running. Most a= pplications. Old, probably XWayland, applications work. Telegram-desktop, a= rox-terminal, browser was able to run - net-surf. > > Errors during launch vary, but almost everything is united by "operation = not supported (os error 45)" > Well, yes, Wayland compositors start and work without problems (hyprland,= labwc, hikari), errors occur when launching compositors clients - applicat= ions. Identify the simplest application that fails and launch it with "truss -o out.txt". Share the very end of this file that shows what actually fails with error 45. From nobody Wed Nov 26 21:31: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 4dGt6P16h9z6HXJF for ; Wed, 26 Nov 2025 21:31:25 +0000 (UTC) (envelope-from drsnx60@gmail.com) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 4dGt6N23kbz3bdS for ; Wed, 26 Nov 2025 21:31:24 +0000 (UTC) (envelope-from drsnx60@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-37b9728a353so3022161fa.0 for ; Wed, 26 Nov 2025 13:31:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764192682; x=1764797482; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=rKGfSdU4LFnSFAZirTPziWg8riPRYyAA3ItCAMNYPRs=; b=Ga4jBvS1EAB8Oziz+x++GyeLx7aEvBo9Hnbr6Vy4TpSRVKI9YDDa4WKLVkQPpGCSnm B2lKJu8HWWrZQx+Ix1tN6CBc4Z35xqzJEcFrUD1GQNG8p+hXLzX1hweJTryWNo2CfBwJ kwHYc1MNJgMFSQicqX3VGllzDTAD7zccLmgtwaa+0FUBYOwSpaahGO3ITakDVRYgk7XJ Vg7kxQJ8i+VuNnFnjpXDxrz56we7K21l++ZZcGkVsILofbYCEyYaSp548jYCzF2xxCwM xwxDOxkwoYJd/Uo0PNdHux4PfENsVHnVeLMhXATXg0ZnA3SMlQjD2m4IKVeNpc7Ma7kQ al4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764192682; x=1764797482; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rKGfSdU4LFnSFAZirTPziWg8riPRYyAA3ItCAMNYPRs=; b=hN7QINFMZNU/azbzdPhw+edlZ1ewJdigQOjIiSGioy33KSRYo8hiLsn03n2o4y2TT0 /0orAHXbLS1dF5LLp28cGryOhVlanIgIp2cWDDphpHL8LF6VXqSR0PzBlY2toK9W5KDX 2yQepOMfJ0iQqr+ec0WQ/v5FfRuEGfB4m4PcdXtqTwWoNrhgGBdZ4kbQORuUe57kN9Ha tKh4tycq/ReJuwJtNweva0lrq00XKDakQwV7rqjTvSNvK7zmVqHSCl4yBS8MEpuvrr87 rx+p84pgXLgIO4OnQ+RywygqhRGUhgcdMEMZoEojFy6/JzgfxaLaktR0dx0GCuqV86Yl e8PA== X-Forwarded-Encrypted: i=1; AJvYcCWMFY67D3OnhjfWLekhMwI9y9cTaZjljU4oZBykCpD36JBZ2YGeQ0+JYaVhgeTgz63+v3zMA9hmYYIdTED2avY=@freebsd.org X-Gm-Message-State: AOJu0Yz8HPWrZM06A/MFAmhs7hcqwEd7cj561kOjqrpAASbqORZro9Jf 3/ETsRPJ2a1LxD+OZB9BAbAxh4PS0i+Fwonq0sbTkDxUPeCoG9o1dLk1UVqGortL X-Gm-Gg: ASbGnctbqcmuvS5r/EcbFZzk4VSRZcCGeaTO+0eORicM6uA4l6AlMRzKKTzaKR9kWE/ zUhaNjlAFVT+OGLnxOQauZ37kpJwEg38A7HlsC4hWAJgjI0DdSTN9MVDbStxFI3guOicCJrr3hB QQ8IoUSiQHSGNrSpE+tAT29F7QJd3SeDfgGy4rzD4aHELcVKzfFpt94hQ+jbXNT52JTiggan29z GSP+IZvbS+g0eNo2mrHpBxPbE19PFIansI1GPL2ibn6NDdsfq9+fs42w6s+ym5UjMxSbm46hjgu Yr5wLoyGiXpGpASfU6I863BSTwZhZoYHh/mOQOVPdheoF0LxxeeBilp9DD+oQCl2goCnifnbZHj Be2ZetG4CkKFMappwUgOiOGKRts8NYZCEPQT3HqIAoLZQ5LLjElUSyYle4rFXnHQGnSEeRvox9i Bi3z5rRGPbieHlw/6VQxOEDRM= X-Google-Smtp-Source: AGHT+IFcBf/ZhstiRhjDppndT3/Ohmxuj9GvOiptanRrNZp25qzhMMl/AYMp19t6+iJ0FynkSNi48w== X-Received: by 2002:a05:6512:238b:b0:594:51bd:8fcd with SMTP id 2adb3069b0e04-596a3eac930mr7965082e87.16.1764192681337; Wed, 26 Nov 2025 13:31:21 -0800 (PST) Received: from [192.168.2.131] (host.62.13.8.86.bitcom.se. [62.13.8.86]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5969dbcd26csm6328942e87.95.2025.11.26.13.31.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Nov 2025 13:31:20 -0800 (PST) Message-ID: <77c2a2fb-ac5f-4b4a-98c6-660a39ee87b2@gmail.com> Date: Wed, 26 Nov 2025 22:31:20 +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 Subject: Re: FreeBSD/X11: Howto revive DisplayPort? To: FreeBSD User , freebsd-x11@freebsd.org, freebsd-current@freebsd.org References: <20251126163059.3376d3e8@hermann> Content-Language: sv-SE From: Lars Tunkrans Organization: Retiered In-Reply-To: <20251126163059.3376d3e8@hermann> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.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: 4dGt6N23kbz3bdS HI    Yes I  have  same experience.    I beleive its because the  DDC/ EDID   info sent from screen over  the  connection cable    is  lost  if  the  KVM  and screen is not connected to the computer at start up.     If I make sure that  the screen is attached to  the computer when the computer powers up      a  Usable resoultion/timing is selected by the graphics card.   Regards. Den 2025-11-26 kl. 16:37, skrev FreeBSD User: > Using FreeBSD CURREN and FreeBSD STABLE/15. > Also, most systems are attached to a KVM switch, connected via DP. > > Hosts booting all UEFI. > > On hosts using X11/xdm GUI, switching forth and back to the output/host I want to use > DP does obviously not "lose" DP output, so after graphics has been initialized I'm able > to see the GUI. > > The situation is completely different with plain consoles, provided by FreeBSD's EFI/UEFI > simple framebuffer device driver. Working on the console on one host, switching to > another host, working there and trying to switch back leaves me with no output anymore! I > see this behaviour with different types of KVM switches I have at hand. > > Can this behaviour be changed, even with no X11? > > Thanks in advance and wishes, > > O. Hartmann > -- ------------------------- Lars Tunkrans Oracle SPARC/Solaris System Administrator Fujitsu M12 SPARC Specilaist From nobody Wed Nov 26 22:03: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 4dGtr65hGWz6Hbnq for ; Wed, 26 Nov 2025 22:04:06 +0000 (UTC) (envelope-from opensource@uitveenendaal.nl) Received: from mailrelay1.mijnmailprovider.nl (mailrelay1.mijnmailprovider.nl [46.235.45.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dGtr447YRz3kKJ for ; Wed, 26 Nov 2025 22:04:04 +0000 (UTC) (envelope-from opensource@uitveenendaal.nl) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of opensource@uitveenendaal.nl designates 46.235.45.172 as permitted sender) smtp.mailfrom=opensource@uitveenendaal.nl Received: from mailnode8.webreus.email (unknown [46.235.42.205]) by mailrelay1.mijnmailprovider.nl (Postfix) with ESMTP id A336C36A63 for ; Wed, 26 Nov 2025 23:03:56 +0100 (CET) Received: from localhost (unknown [127.0.0.1]) by mailnode8.webreus.email (Postfix) with ESMTP id 9909F105730A for ; Wed, 26 Nov 2025 22:03:56 +0000 (UTC) Received: from mailnode8.webreus.email ([127.0.0.1]) by localhost (mailnode8.webreus.email [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bmvqj5EbxT1W for ; Wed, 26 Nov 2025 23:03:56 +0100 (CET) X-MMP-Auth-Sender: opensource@uitveenendaal.nl Received: from [192.168.88.38] (unknown [45.142.235.164]) (Authenticated sender: opensource@uitveenendaal.nl) by mailnode8.webreus.email (Postfix) with ESMTPA id 8031E10572EA for ; Wed, 26 Nov 2025 23:03:56 +0100 (CET) Content-Type: multipart/alternative; boundary="------------h0z3IqEPRGZzaIXKaJqoZBgr" Message-ID: <4fdaa5fc-1cef-43d6-adba-65fa18b35ee2@uitveenendaal.nl> Date: Wed, 26 Nov 2025 23:03:56 +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 Subject: Re: HP ProBook 6550b hangs on kernels above 14.0-RELEASE Content-Language: en-US References: To: freebsd-current@FreeBSD.org From: Michael In-Reply-To: X-Forwarded-Message-Id: X-Spamd-Bar: / X-Spamd-Result: default: False [0.68 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_SPAM_MEDIUM(1.00)[0.996]; NEURAL_SPAM_LONG(0.98)[0.979]; R_SPF_ALLOW(-0.20)[+ip4:46.235.45.128/25]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[uitveenendaal.nl]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:213192, ipnet:46.235.40.0/21, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RECEIVED_HELO_LOCALHOST(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4dGtr447YRz3kKJ This is a multi-part message in MIME format. --------------h0z3IqEPRGZzaIXKaJqoZBgr Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian! Thanks for looking into this! Yes, it might very well be an ACPI-issue. I noticed the kernel is not completely locked up when I boot 16.0-CURRENT. If I do a verbose boot and press the power button (at the point where the system has stopped booting) another message appears on the console: AcpiOsExecute: task queue not started Every time I press the power button this line gets repeated. I'm not sure if this is helpful in providing info about the hardware in this laptop but I installed 14.0-RELEASE on it so I could run pciconf -l -v, devinfo -r -v and do a verbose boot. If you need more info, just let me know. And if there is anything I can do so you don't have to get one of these laptops let know too. The output of the commands seems a bit much to include in this mail so they're at pastebin: devinfo: https://pastebin.com/6svCYbCF pciconf: https://pastebin.com/N2TJKHLx Kind regards! Michael On 22-11-2025 16:30, Adrian Chadd wrote: > hi! > > The observation in the post about it being ACPI is also very valid. > > Can you share more specific details about the hardware in the laptop? > It looks like I can pick one up cheap on ebay, > and if it's an ACPI problem i'm likely going to need to add printf > debugging everywhere to give the ACPI maintainer > some more information. ;-) > > > > -adrian > > > On Tue, 18 Nov 2025 at 11:21, Michael wrote: > > Hello, > > ==== > One of my old laptops (HP ProBook 6550b) was running FreeBSD > 14.0-RELEASE (amd64) perfectly fine, but upgrading to anything higher > results in a boot that hangs at the line: > psm0: model Synaptics Touchpad, device ID 0 > > A while ago I tried upgrading to 14.1-RELEASE and run into this > problem. > Back then I decided to wait, hoping this glitch would be ironed > out in a > later release. But today experimenting with 14.3-RELEASE and > 15.0-STABLE > from 20251113 I got the same results. > > It would be great to find a fix for this and would like to help > troubleshooting this issue. I'm not even close to a kernel developer > though, but perfectly capable of gathering all kinds of > information (I'm > a FreeBSD-user since version 4.4) and help testing. > ==== > > This is what I posted on the FreeBSD forum. The post is here: > https://forums.freebsd.org/threads/hp-probook-6550b-not-booting-14-3-release-15-0-stable.100065/ > > The conclusion there was to try again on this mailing list. > > I tried kernels 14.1-RELEASE, 14.3-RELEASE, 15.0-STABLE and the most > recent version I tested with is > FreeBSD-16.0-CURRENT-amd64-20251110-dbb34d496708-281771 > The problem is still there. It seems the system locks up since > scolling > back up doesn't work either. > > I wonder if anyone is willing to look into this. The offer to help > troubleshooting this and test a solution (if any) stands. > > Kind regards, > Michael > --------------h0z3IqEPRGZzaIXKaJqoZBgr Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Adrian!

Thanks for looking into this!

Yes, it might very well be an ACPI-issue. I noticed the kernel is not completely locked up when I boot 16.0-CURRENT. If I do a verbose boot and press the power button (at the point where the system has stopped booting) another message appears on the console:

AcpiOsExecute: task queue not started

Every time I press the power button this line gets repeated.

I'm not sure if this is helpful in providing info about the hardware in this laptop but I installed 14.0-RELEASE on it so I could run pciconf -l -v, devinfo -r -v and do a verbose boot.

If you need more info, just let me know.
And if there is anything I can do so you don't have to get one of these laptops let know too.

The output of the commands seems a bit much to include in this mail so they're at pastebin:
devinfo: https://pastebin.com/6svCYbCF
pciconf: https://pastebin.com/N2TJKHLx

Kind regards!
Michael


On 22-11-2025 16:30, Adrian Chadd wrote:
hi!

The observation in the post about it being ACPI is also very valid.

Can you share more specific details about the hardware in the laptop? It looks like I can pick one up cheap on ebay,
and if it's an ACPI problem i'm likely going to need to add printf debugging everywhere to give the ACPI maintainer
some more information. ;-)



-adrian


On Tue, 18 Nov 2025 at 11:21, Michael <opensource@uitveenendaal.nl> wrote:
Hello,

====
One of my old laptops (HP ProBook 6550b) was running FreeBSD
14.0-RELEASE (amd64) perfectly fine, but upgrading to anything higher
results in a boot that hangs at the line:
psm0: model Synaptics Touchpad, device ID 0

A while ago I tried upgrading to 14.1-RELEASE and run into this problem.
Back then I decided to wait, hoping this glitch would be ironed out in a
later release. But today experimenting with 14.3-RELEASE and 15.0-STABLE
from 20251113 I got the same results.

It would be great to find a fix for this and would like to help
troubleshooting this issue. I'm not even close to a kernel developer
though, but perfectly capable of gathering all kinds of information (I'm
a FreeBSD-user since version 4.4) and help testing.
====

This is what I posted on the FreeBSD forum. The post is here:
https://forums.freebsd.org/threads/hp-probook-6550b-not-booting-14-3-release-15-0-stable.100065/

The conclusion there was to try again on this mailing list.

I tried kernels 14.1-RELEASE, 14.3-RELEASE, 15.0-STABLE and the most
recent version I tested with is
FreeBSD-16.0-CURRENT-amd64-20251110-dbb34d496708-281771
The problem is still there. It seems the system locks up since scolling
back up doesn't work either.

I wonder if anyone is willing to look into this. The offer to help
troubleshooting this and test a solution (if any) stands.

Kind regards,
Michael


--------------h0z3IqEPRGZzaIXKaJqoZBgr-- From nobody Wed Nov 26 23:00: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 4dGw5Z0JY2z6HjSl for ; Wed, 26 Nov 2025 23:00:50 +0000 (UTC) (envelope-from olivier@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 4dGw5Y6klXz3pqM for ; Wed, 26 Nov 2025 23:00:49 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764198050; 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=82L/tfLQ1K6BbHPZLSDvQuoBDG2in4G/p4BlDV8ZwAQ=; b=PWVwEaYpi+00xYgS9term4ZUp+tZy90iUVfeZXE+pEHTN/916kmsOQQJVSShhkcWMHiGTt zGsizuiF8ADJSzaO2oSR9yjpd7a9ZQXoY1wl+YSNWCR3kfGq92hbaxq3N95NTWY8i0QwaR E+3M1qa0EEYWWvPD0mEKpYHdES/NK0FtQK5K+m2ycNb9DK1uE4A1oFnmfDHGa3jKiLgetb +FPdhf7lDNSrehClmelVD95zWnuEdYSJXYITF+TKrjv6b9e4l7C/C9O7BQx/27V6SRVL/5 nNLqmydttljkGrUnFK6MbUlEMwH7lc5i4G3UnUkRtEdhKHg7B3fsyKztAwzBNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764198050; 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=82L/tfLQ1K6BbHPZLSDvQuoBDG2in4G/p4BlDV8ZwAQ=; b=wV7wZHMCswxaCFrRCnFouBuZJwi0cGsllfOFD4qfjQEotZKFMS+IBL/iGNAcLcNpadtLEC tN4OlfxuZJoVQiX5jSum6QFxClOy7yh2LDNJWcrsiTp8Gbr1P8AW5KoD/BsQin3sYgN1to PAmVApliba1LolgJMJqRIJDTapcMylJ6ihOpmYBht2Jle2IXFXEyYBS3K0pW+oXUlD42BT 1i4JRsEjePUCXCO89zwyiSltmw5z0qXYo4T2b+qVizoirQuxIpjnn1H6QxqjwYgPS0I0Gw LV8jL1p4FOcmA/bNQQ/wV6qdtYc9SD1Q/PLtrKd0/0hgycZMJyMG1KM7AF8XQg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764198050; a=rsa-sha256; cv=none; b=AMJSaTpP4brkxlNxlfpXtIg0ox52JYnTkZN6FCPFVJ/FJcvVCMx5mSqRaCPqGwHJWq4avq ycPeVv5jjwanc+2fuJI7wI6db4Dmv/Voq2gPuAdrWch1xNjMoHEsiY4SRC7I4uUgLsYW0F m7VryJjTPhCeToTMxBQwsy5hndVOMqcsT1kSiRtJjZbLD0zx1zkc5q3f7aAC6BvqpmiUJS 5IeCdGoSPugo2BIG5SCdxFooGASOX5wKPv96MjPlwwSOxa8/G42jB700PeiVB92lm9lWaR CpjmxsLcC8mq2sJ8llN6+XrGJx0Ndz+Gh4tapG+CjDh6Bfdd5QGRRTec6pBBLw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) (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)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dGw5Y5nq1z17W5 for ; Wed, 26 Nov 2025 23:00:49 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-88246676008so2804466d6.3 for ; Wed, 26 Nov 2025 15:00:49 -0800 (PST) X-Gm-Message-State: AOJu0Yy4LB5ifAkkyi4cHB4seg/CvgYW0jKyqbdMjAHYGl/uprT0yxXs SfEV04OBUh4QXwJ/72IAcmjCT/r09QjwRLELSN11/60Ut2AqURglVGtWpifmUsDTpjvVmOb3Ke6 EGleEoGN9O9VhH1PmbWQ72ubgY5IxKHM= X-Google-Smtp-Source: AGHT+IFpH0igPki8pdOBeY1n9PxEqCtUVk0ru4sYZ8ojkW1L8tejrMqmMhwovdbhslboWNuzrToMBTCroMoLZZe33Cs= X-Received: by 2002:a05:6214:ac3:b0:882:4987:360 with SMTP id 6a1803df08f44-8847c57db56mr347452286d6.62.1764198049312; Wed, 26 Nov 2025 15:00:49 -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: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Thu, 27 Nov 2025 00:00:37 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_blm3VeJU8rnHD60vjjEpTGOCwfMKBgHTnrZ2LqU3t-AwSTcSprtuP0k3q0 Message-ID: Subject: Re: November 2025 stabilization week To: freebsd-current@freebsd.org, src-committers@freebsd.org Cc: Gleb Smirnoff Content-Type: multipart/alternative; boundary="0000000000000b01a50644875e81" --0000000000000b01a50644875e81 Content-Type: text/plain; charset="UTF-8" Hi, The regression regarding the use of bectl activate -t has been addressed and committed. The fix was pushed by imp@ in the following commit: "git: 3e69618d4bfb - main - openzfs: We are FreeBSD, not posix" For context, please note that this issue was only triggered when using the -t option of bectl; the tools/build/beinstall.sh utility does not utilize this option. As no further critical reports have been received, I am officially declaring the stabilization week concluded. Thanks to everyone for your contributions. Regards, Olivier --0000000000000b01a50644875e81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The= regression regarding the use of bectl activate -t has been addressed and c= ommitted.

The fix was pushed by imp@ in the following commit:
&qu= ot;git: 3e69618d4bfb - main - openzfs: We are FreeBSD, not posix"
<= br>For context, please note that this issue was only triggered when using t= he -t option of bectl; the tools/build/beinstall.sh utility does not utiliz= e this option.

As no further critical reports have been received, I = am officially declaring the stabilization week concluded.

Thanks to = everyone for your contributions.

Regards,

Olivier
=
--0000000000000b01a50644875e81-- From nobody Thu Nov 27 05:31:34 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 4dH4mW4PQZz6JSDX; Thu, 27 Nov 2025 05:31:39 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4dH4mW25BTz3Z1Z; Thu, 27 Nov 2025 05:31:38 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id CC064240261; Thu, 27 Nov 2025 06:31:36 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 444002402A8; Thu, 27 Nov 2025 06:31:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764221495; 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=MyObN1ivisvD3/38R4rP9h5rqrPVAVHIUPPwOAvpYQ4=; b=CtEPRFbu/qEqdNuLXZqFkJ4XV6C8sE76yn6cGnJKRqkRMpd7T2rNwBncHubMTvU8EcDpXs Epruv2saxFcgmqL84czPQAP2xPB8NNvWbroQ1AfNuM+S6NWFWb0WSXizGXQINVCMGpQFDj J6nJPTDnwbv4gvKXyzQDj+MuaJImOB98Pqwaw+ksc6BmOxVWyd+3ORtNUsnqjgeN/gHz3+ k8ZPnIXBMQV2bErqja/deozQT4dcsTH00VnQyXbPi1p77Iz4pQ3ROSocTQWl2E4scabuxO Qf/W3Vy9VD5EUvHxO8VeJw4GnV8JktEGqA86B+0hwiX5r9o2KpLBzNfx0L0wrw== Received: from hermann (dynamic-2a02-3100-2eb7-8202-be6c-e0ee-39e6-fd11.310.pool.telefonica.de [IPv6:2a02:3100:2eb7:8202:be6c:e0ee:39e6:fd11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 07D1C240240; Thu, 27 Nov 2025 06:31:35 +0100 (CET) Date: Thu, 27 Nov 2025 06:31:34 +0100 From: FreeBSD User To: Lars Tunkrans Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: FreeBSD/X11: Howto revive DisplayPort? Message-ID: <20251127062631.5d8026c4@hermann> In-Reply-To: <77c2a2fb-ac5f-4b4a-98c6-660a39ee87b2@gmail.com> References: <20251126163059.3376d3e8@hermann> <77c2a2fb-ac5f-4b4a-98c6-660a39ee87b2@gmail.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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-UID: 4c80ce X-Rspamd-UID: 342378 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: 4dH4mW25BTz3Z1Z On Wed, 26 Nov 2025 22:31:20 +0100 Lars Tunkrans wrote: > HI >=20 > =C2=A0 =C2=A0Yes I=C2=A0 have=C2=A0 same experience. >=20 > =C2=A0 =C2=A0I beleive its because the=C2=A0 DDC/ EDID=C2=A0 =C2=A0info = sent from screen over=C2=A0=20 > the=C2=A0 connection cable > =C2=A0 =C2=A0is=C2=A0 lost=C2=A0 if=C2=A0 the=C2=A0 KVM=C2=A0 and screen= is not connected to the computer=20 > at start up. > =C2=A0 =C2=A0 If I make sure that=C2=A0 the screen is attached to=C2=A0 = the computer when=20 > the computer powers up > =C2=A0 =C2=A0 =C2=A0a=C2=A0 Usable resoultion/timing is selected by the = graphics card. >=20 > =C2=A0 Regards. Exactly. this behaviour is observed by myself on FreeBSD, Linux or Windows, on the c= ontrary, seems to have a solution to reestablish a DP connection, so it might be possible = on FreeBSD also (but is somehow by default disabled, I hope). Having for computer attached to one KVM, three of them are FBSD boxes and o= ne is a Linux based commercial product provided by my employer leaves me with trouble whe= n powering up all machines. Kind regards, oh >=20 >=20 > Den 2025-11-26 kl. 16:37, skrev FreeBSD User: > > Using FreeBSD CURREN and FreeBSD STABLE/15. > > Also, most systems are attached to a KVM switch, connected via DP. > > > > Hosts booting all UEFI. > > > > On hosts using X11/xdm GUI, switching forth and back to the output/host= I want to use > > DP does obviously not "lose" DP output, so after graphics has been init= ialized I'm > > able to see the GUI. > > > > The situation is completely different with plain consoles, provided by = FreeBSD's > > EFI/UEFI simple framebuffer device driver. Working on the console on on= e host, > > switching to another host, working there and trying to switch back leav= es me with no > > output anymore! I see this behaviour with different types of KVM switch= es I have at > > hand. > > > > Can this behaviour be changed, even with no X11? > > > > Thanks in advance and wishes, > > > > O. Hartmann > > =20 From nobody Thu Nov 27 11:53: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 4dHFF56cZkz6JCp3 for ; Thu, 27 Nov 2025 11:53:29 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) (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 4dHFF471Z0z3G4G for ; Thu, 27 Nov 2025 11:53:28 +0000 (UTC) (envelope-from 6yearold@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 6yearold@gmail.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=6yearold@gmail.com Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-787d5555274so8043467b3.1 for ; Thu, 27 Nov 2025 03:53:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764244407; x=1764849207; 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=X7hK7evLmvsZ22bz4bICSOtIv5U/g1AtzUmAY6coUeI=; b=kc4ZjHHqf6CwlHz+2jjzZC3eq/WgSljHCVTtbAcBqFlvQYFtfRw9WsR1GymP47aB+c Ff9zCrKVLY9Rfp7XGnATcg6Xtb23URsymT1XB2+ky7eEffGRQtcTumOgtHIaF58bmAKy +WyFkbMUo/zR/CGBDap2nCM+x/GeKHtvsQOi2tj1s0BjP7Za9Y55ks20BXgFeBofZYjv mfHyC9b/cPMATZHYi/OsUtFc9pals0Wjnp06zXtR+WXZZITdxuFWdSWQfDX0oKwlr9ma pks0iDwlzioGcE+jeJ3m6MEPkB9PHf1ZcBmhXqf6TH2nsHKQOQadpDFyTyFb/p5Wvjbm d+mw== X-Gm-Message-State: AOJu0Yx40I7FHImH+waEM7Pa0enXokR1zWmD0I8lfT1avn3L7ppgfyGN Af1hiOeLBBci/NBoxeNmIyoDpFk7NJG2Oy8/7dVIcqBP8NcNcPZgvP0LOtvobsFI X-Gm-Gg: ASbGncsV2SLvry6RThnN4xc6BMRLejQB0R/bRJP+1vqAQrlf0hr4Q/gxarPAP2hvAqr SnzxyKAxfFMohDQ3/2RfFeqVOWrrNGF3R7Pm+/OVIVsCwidrdoS7xl78FhVWAs7Z1EyeSkaDd4a SEsmgAGvjFqxd8UHWQFVwOJndTatwkYiif+kEa+13SHSOf31XNa9dbYPsjbSOZFU1Cb0x4oxsBD aJ6caQ5/gANoNeQtVrAtTYg0l2Oyl+uQgh3poV063iNswb+/oK5Rg7aib1SuV1tf+dTBTuAzHdl 2C2uHqCOUUMwjzKlGZg+TM6jvL/VOqvVrN6oRXVsA9e8IcgBJOP83CjDQeS7zOSoSsyq0DhSsK5 TcRbQ4ebEn5AO+7cTpj5GOA3vqQn8rrQj3KEZJ2eYSE02seU5M1fBwfvkrVqhx9hixumm/d4NKR BBQ3//prOho4dHxmWq8cc6qtqdyEczytNS5j2ZRTaFGW4NvxWxIQ== X-Google-Smtp-Source: AGHT+IE09y4GzkCgpYzWA4GHEWxzVWXz3Mjr+O1yj+wtSoxY7LSeJLfVTaVQnHf5oEo88zaaWx0fjw== X-Received: by 2002:a05:690c:3583:b0:788:1cde:cae2 with SMTP id 00721157ae682-78ab6fce6demr102111607b3.67.1764244407625; Thu, 27 Nov 2025 03:53:27 -0800 (PST) Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com. [209.85.128.171]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78ad1045790sm4745537b3.50.2025.11.27.03.53.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Nov 2025 03:53:27 -0800 (PST) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-78802ac22abso8317247b3.3 for ; Thu, 27 Nov 2025 03:53:27 -0800 (PST) X-Received: by 2002:a05:690c:7249:b0:787:bfba:b84b with SMTP id 00721157ae682-78ab6e105bfmr97894007b3.28.1764244407069; Thu, 27 Nov 2025 03:53:27 -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: <11071764173299@mail.yandex.ru> <46931764229021@mail.yandex.ru> In-Reply-To: <46931764229021@mail.yandex.ru> From: Gleb Popov Date: Thu, 27 Nov 2025 14:53:00 +0300 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bkGnRHO0C3EEs2BGXwiET3NMSI-o2Jo2LiK58iNa-lhYiOG11MepE6ofoE Message-ID: Subject: Re: operation not supported Wayland To: =?UTF-8?B?0JvQtdC+0L3QuNC0INCT0L3QtdC30LTQuNC70L7Qsg==?= Cc: "freebsd-current@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Spamd-Result: default: False [0.65 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.86)[-0.861]; NEURAL_SPAM_MEDIUM(0.41)[0.413]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.174:from]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; RCVD_COUNT_THREE(0.00)[3]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.174:from,209.85.128.171:received]; RCPT_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4dHFF471Z0z3G4G On Thu, Nov 27, 2025 at 10:40=E2=80=AFAM =D0=9B=D0=B5=D0=BE=D0=BD=D0=B8=D0= =B4 =D0=93=D0=BD=D0=B5=D0=B7=D0=B4=D0=B8=D0=BB=D0=BE=D0=B2 wrote: > > + freebsd-current@ > > there are two out files in the attachment - runs alacritty and doublecmd To me it looks like something is out of sync. How are you getting your packages? Are you using official repo or building it yourself? From nobody Thu Nov 27 15:47: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 4dHLRV4smSz6HTdB; Thu, 27 Nov 2025 15:47:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHLRV2d1tz40P1; Thu, 27 Nov 2025 15:47:50 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002b.ext.cloudfilter.net ([10.228.9.233]) by cmsmtp with ESMTPS id OdQBvKetEPzKyOeDlvQ1ua; Thu, 27 Nov 2025 15:47:49 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id OeDjvRhB7UZWaOeDkv26sK; Thu, 27 Nov 2025 15:47:49 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=Ls6fC3dc c=1 sm=1 tr=0 ts=692872a5 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=IkcTkHD0fZMA:10 a=6UeiqGixMTsA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YxBL1-UpAAAA:8 a=pGLkceISAAAA:8 a=CeIHQudJlSsTNqHkSmQA:9 a=QEXdDO2ut3YA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy.cwsent.com [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 4056FD8; Thu, 27 Nov 2025 07:47:47 -0800 (PST) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (Postfix) with ESMTP id 2CDA330E; Thu, 27 Nov 2025 07:47:47 -0800 (PST) Date: Thu, 27 Nov 2025 07:47:47 -0800 From: Cy Schubert To: FreeBSD User Cc: Lars Tunkrans , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: FreeBSD/X11: Howto revive DisplayPort? Message-ID: <20251127074747.2c250a85@slippy.cwsent.com> In-Reply-To: <20251127062631.5d8026c4@hermann> References: <20251126163059.3376d3e8@hermann> <77c2a2fb-ac5f-4b4a-98c6-660a39ee87b2@gmail.com> <20251127062631.5d8026c4@hermann> Organization: KOMQUATS X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd16.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfCafrCaaoKsnHc/ECiGiCl5IxalzKGTTEPODlHQy99GpFkFx9/MtRNqJAXPmO4JvHHDtwcglZhzSzPK6HecPhGduWpRF7Vt5pyxV47mkRfPazDLw8ITW Lj49GcdreQp7WpN8XJ5sben0XW3q38cVantFR15EOEhCkoOQShhwWfsnmqtFHAfKmPMZ4WVKZ0iqUcnlke33WzAFKpBRljReQqcDhwUWBH/RWwow/hUwGPto eLNWegJpa6e9Eg0snEFWr9TYMT7velJvfO4652qgiqkS2u3HmNSb0yqPtfZN3I5+6B6LRFSTVEAl2qbHk2jSCQ== X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dHLRV2d1tz40P1 One of HP 840 G5's docking station's DPs is connected to a VGA KVM switch via a DP to VGA connector. Confirmed, this is an issue. The VGA KVM switch is also connected to my employer's HP 840 G9, also via a DP to VGA connector. No problems there. Though that machine uses the newer Thunderbolt docking station. Given that it's a newer machine with a newer docking station I think the comparison only goes so far. Whether this is a FreeBSD or a UEFI BIOS problem isn't quite understood by me. When booting the FreeBSD machine and if the KVM is not switched to the FreeBSD machine, the text mode console will have the wrong geometry. Even in single user the login prompt is far below the bottom of the monitor. But once XDM has started it assumes a graphic geometry that fits the laptop's screen, not the external monitor. I have a script that disables the LVDS when the VGA is connected. I suspect that this problem will require more tinkering (not by myself) to better understand it. There are too many variables to say it's a single issue. Another issue is, X segfaults on occasion on this machine. The segfault always occurs when firefox is active. The screen goes blank as drm-66-kmod (I think) is corrupted. (This happens maybe once or twice a month, not enough to pull me away from other projects.) Are you talking about this or the first issue above? --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=3D0 On Thu, 27 Nov 2025 06:31:34 +0100 FreeBSD User wrote: > On Wed, 26 Nov 2025 22:31:20 +0100 > Lars Tunkrans wrote: >=20 > > HI > >=20 > > =C2=A0 =C2=A0Yes I=C2=A0 have=C2=A0 same experience. > >=20 > > =C2=A0 =C2=A0I beleive its because the=C2=A0 DDC/ EDID=C2=A0 =C2=A0inf= o sent from screen over=C2=A0=20 > > the=C2=A0 connection cable > > =C2=A0 =C2=A0is=C2=A0 lost=C2=A0 if=C2=A0 the=C2=A0 KVM=C2=A0 and scre= en is not connected to the computer=20 > > at start up. > > =C2=A0 =C2=A0 If I make sure that=C2=A0 the screen is attached to=C2= =A0 the computer when=20 > > the computer powers up > > =C2=A0 =C2=A0 =C2=A0a=C2=A0 Usable resoultion/timing is selected by th= e graphics card. > >=20 > > =C2=A0 Regards. =20 >=20 > Exactly. > this behaviour is observed by myself on FreeBSD, Linux or Windows, on the= contrary, seems > to have a solution to reestablish a DP connection, so it might be possibl= e on FreeBSD > also (but is somehow by default disabled, I hope). >=20 > Having for computer attached to one KVM, three of them are FBSD boxes and= one is a Linux > based commercial product provided by my employer leaves me with trouble w= hen powering up > all machines. >=20 > Kind regards, >=20 > oh >=20 > >=20 > >=20 > > Den 2025-11-26 kl. 16:37, skrev FreeBSD User: =20 > > > Using FreeBSD CURREN and FreeBSD STABLE/15. > > > Also, most systems are attached to a KVM switch, connected via DP. > > > > > > Hosts booting all UEFI. > > > > > > On hosts using X11/xdm GUI, switching forth and back to the output/ho= st I want to use > > > DP does obviously not "lose" DP output, so after graphics has been in= itialized I'm > > > able to see the GUI. > > > > > > The situation is completely different with plain consoles, provided b= y FreeBSD's > > > EFI/UEFI simple framebuffer device driver. Working on the console on = one host, > > > switching to another host, working there and trying to switch back le= aves me with no > > > output anymore! I see this behaviour with different types of KVM swit= ches I have at > > > hand. > > > > > > Can this behaviour be changed, even with no X11? > > > > > > Thanks in advance and wishes, > > > > > > O. Hartmann > > > =20 >=20 >=20 From nobody Thu Nov 27 16:44: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 4dHMhx6kytz6HbW8 for ; Thu, 27 Nov 2025 16:44:33 +0000 (UTC) (envelope-from ross@bisd.ro) Received: from ada.kiz.li (ada.kiz.li [38.45.72.165]) (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 4dHMhw1xTrz4CTn for ; Thu, 27 Nov 2025 16:44:32 +0000 (UTC) (envelope-from ross@bisd.ro) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=bisd.ro; spf=pass (mx1.freebsd.org: domain of ross@bisd.ro designates 38.45.72.165 as permitted sender) smtp.mailfrom=ross@bisd.ro Received: from [10.116.181.102] (200.sub-174-205-96.myvzw.com [174.205.96.200]) by ada.kiz.li (OpenSMTPD) with ESMTPSA id 67310feb (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Thu, 27 Nov 2025 11:44:24 -0500 (EST) Content-Type: multipart/alternative; boundary="------------EfMYkLc3fJm1qdlWmtwli0Oa" Message-ID: Date: Thu, 27 Nov 2025 10:44:23 -0600 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: operation not supported Wayland To: freebsd-current@freebsd.org References: <11071764173299@mail.yandex.ru> Content-Language: en-US From: "S. Ross Gohlke" In-Reply-To: <11071764173299@mail.yandex.ru> X-Spamd-Bar: / X-Spamd-Result: default: False [0.40 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.99)[0.989]; NEURAL_HAM_SHORT(-0.98)[-0.985]; DMARC_POLICY_ALLOW(-0.50)[bisd.ro,reject]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4dHMhw1xTrz4CTn This is a multi-part message in MIME format. --------------EfMYkLc3fJm1qdlWmtwli0Oa Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/26/25 10:11, Леонид Гнездилов wrote: > Hi! > FreeBSD 16.0-CURRENT, Wayland. After the one of upgrade (or after some > of my experiments with the system), many applications stopped running. > Most applications. Old, probably XWayland, applications work. > Telegram-desktop, a rox-terminal, browser was able to run - net-surf. > > Errors during launch vary, but almost everything is united by > "operation not supported (os error 45)" > Well, yes, Wayland compositors start and work without problems > (hyprland, labwc, hikari), errors occur when launching compositors > clients - applications. I am running a Wayland session on FreeBSD 16.0-CURRENT pkgbase from a couple of weeks ago and have not seen these errors. Wayfire is the compositor, and my regular app rotation -- foot, Firefox, Thunderbird -- is as stable as it has been. I am not using XWayland. If there are specific apps you would like me to check let me know. Regards, Ross --------------EfMYkLc3fJm1qdlWmtwli0Oa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 11/26/25 10:11, Леонид Гнездилов wrote:

Hi!
FreeBSD 16.0-CURRENT, Wayland. After the one of upgrade (or after some of my experiments with the system), many applications stopped running. Most applications. Old, probably XWayland, applications work. Telegram-desktop, a rox-terminal, browser was able to run - net-surf.

Errors during launch vary, but almost everything is united by "operation not supported (os error 45)"
Well, yes, Wayland compositors start and work without problems (hyprland, labwc, hikari), errors occur when launching compositors clients - applications.

I am running a Wayland session on FreeBSD 16.0-CURRENT pkgbase from a couple of weeks ago and have not seen these errors.

Wayfire is the compositor, and my regular app rotation -- foot, Firefox, Thunderbird -- is as stable as it has been. I am not using XWayland.

If there are specific apps you would like me to check let me know.

Regards,

Ross

--------------EfMYkLc3fJm1qdlWmtwli0Oa-- From nobody Thu Nov 27 17:28:30 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 4dHNgw4VMdz6HhH7 for ; Thu, 27 Nov 2025 17:28:44 +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 4dHNgv6SLVz4KDr for ; Thu, 27 Nov 2025 17:28:43 +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-9486adc1aa9so49511339f.1 for ; Thu, 27 Nov 2025 09:28:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764264523; x=1764869323; h=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=iV0DiKoXydT3Ol23p18Szs5MrDFdt4aYEgABo2Bn6Bs=; b=uDgprvBS76cgxTMz8ZstibnfIg/Br3hzTknt/VNCeMcQpG4DfzHNJ9WYWtXpolKRAp DKsfmLP/wuYVOMhO3ewLtZx42ub6y/05aowF8lsobZxvx39FPexEEVf5Y33zlejQxYmp u3fygbL30Vi4xFs4gl2wkzVRUyaKOMxH0Tugi49ZFZwGx4ZP1kZpz28czsBQe+qomkUi mx5q+oKH9svBoDZJwPsPP91ISRyYZ1CowpZSqPKBMP9UZIiwfG2T3JFxGYL1Tve1cmtQ RkJ5lmyIpp5N4H6NOTR1cmb14E/hTJ+1vaa4fupz6W6PmUq2UMG1w2Xi97ob2OgbEf5Y Eu9Q== X-Gm-Message-State: AOJu0YzK9WEMrZe/eCbIUdGdp12fTXkyDe+1NA5PCMBay29lw8RBz+50 +fhMFE9amQh5TbYCAbZBeStDWi0Z4fqmevr0OjGcXNm77+sYZn8MSGBhS70cFsE0d4DgnuhPkua GayxhlrJs+qTSWvSsq1A0PNRXvHF1wxYO0jX5 X-Gm-Gg: ASbGncsbkOZ78O7kpMnBlMq9coFdb1El5LwwjyXv8nzsMRofbr01qEv0SMATi9Wv5e4 WOUem4fn9P2pHY1LLgDdYOuiflUcrWU7yEgmTM874SC0grW2Tgd9QwTfZn5pTxO/5BkFnZpSqSN AadegGgh6+1TnnUGev+QEqkZRbLCbSCz/5UHA90XzrLcyD5uu0t6SupUTXPOvV1piQ9bW4oeg44 l6Wjydhcy1bpfZ2BcvprCq/jGwX/pQaF4cvkWw2cBgzBhgZekLoO4vmermeVolPnWKejzfEz6H5 u7I49OAdXrZkHiKgjGOOxbE+An4= X-Google-Smtp-Source: AGHT+IGPNFMAuWuSVeyFJ6LFc7SqIB8qBHicozkzu4H4sXbdQ74kEDqKuBe3OY/M5IXXBGifQDkndBEKeuMw8CdDrUg= X-Received: by 2002:a02:ccc3:0:b0:5b7:ba93:6821 with SMTP id 8926c6da1cb9f-5b967a1abdcmr14428971173.9.1764264522822; Thu, 27 Nov 2025 09:28:42 -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: Thu, 27 Nov 2025 12:28:30 -0500 X-Gm-Features: AWmQ_bnyl3Lo50ZdEbEpyLjz2YNgn8pzG95MvPa9KsyjufenCMY9yIwky8RNC5E Message-ID: Subject: Re: Request for testing [was: Heads-up: Kernel module symbol resolution changing] To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.83 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.99)[-0.988]; NEURAL_HAM_MEDIUM(-0.95)[-0.945]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; FREEFALL_USER(0.00)[carpeddiem]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.50:from]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; TO_DN_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.50:from]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4dHNgv6SLVz4KDr On Tue, 25 Nov 2025 at 17:58, Ed Maste wrote: > > ... > > I plan to flip the default soon, in advance of FreeBSD 15.0. See > > PR207898 and https://reviews.freebsd.org/D47742 for more information. > ... > I'm aware of two failures so far: Three more now, 1. cxgbe et al, PR291250 2. bhnd, PR291251 3. e6000sw, PR291252 From nobody Thu Nov 27 18:13: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 4dHPgZ1B2vz6HnF5; Thu, 27 Nov 2025 18:13:30 +0000 (UTC) (envelope-from flo@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 4dHPgZ0Zwjz4QM1; Thu, 27 Nov 2025 18:13:30 +0000 (UTC) (envelope-from flo@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764267210; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=w8W358NjXzDGOB5mMqePwjZVZearD68zWGh5qAulfdE=; b=ZcsejXs0g87PrwC1UMwTMyeLQ4DQUnEIuZLcfki9G5toajhsaI/1p56GdfEIJyniydfclG B4+jOTThFP5mjqmf3QcGR5KqxHeLLQlCnxlgG4ym/+RUO6+ZCKWpZ+2QyBVQiXqrrhoGPX 3CD7n12HkRI7pTSHBQByjX43hgZyP1PmgBeVsEGYQRXQS+i/CK5gY9chEl0q9JpG0t5H+F ULnLv4e7V1YeJdLPHP+S6tMOgjUnZV0xYtC28i1qUL6tzThidWfk58fUPnTKr3ietrxeX3 dlNNP82FohewA8ZPSSSFbio1XTThbLGHwqr2CQIgfoCMCyXeKgKG39GYzSzBZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764267210; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=w8W358NjXzDGOB5mMqePwjZVZearD68zWGh5qAulfdE=; b=h0/5pMjOXoALYSA6fd7Poz3UDjRil07Aeb4Rzq4cj6zu939GqAbfC+NKdwFpvfgeps9+Jq BBUk7PXqWbMQ03jRkXH4nzhZknl/0GQRb1j1ktqfuAIyIwUfnpadx3MlLbp9qblfuLyKMQ WpUnNYfMx4rj5mQNcJ9x+mgOj4VBPXKqhEDo0o7jsNSdUMFiYYsNHXBS9sEqIUdfu+yCNy YFc1/qOViXpYZl87rePAdPFy6GakpMtTwroKJVDAr8ozJ5icl6S06MYCbP1REyzWTXRfJl sN8U091OZPS1oZPARrbYMClKLaql4m9KfLYms5JkCOpMyvC+yZ+0ixrJKmbwng== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764267210; a=rsa-sha256; cv=none; b=qPTYssC1DnFKQZMI+DUPgiNtB5m6CrdVcCk1lzMA7Nl7tGzGiqad+P/YYjVYF4qIQeiyK2 hWxHs8+xT6qd9um9ZzEjrBfSac/ZIE5u1oV7CE3qSV/9DEiwEFHpoU3ecoQckqdESIUWE8 yJ9saojQBcTuuHCI12zT+DWyGGz2mf5qZq96rSMQtrZLZ3o7KHSozvlYh1fHHsZoRI5GmK P9PK4EPSuCZdLUBbBmtX5hY+g7tdUCKAPZMPFrxfE1xMUH3qerx1fkJvarjTtEJSi6sh5j 1kF0pbrNXUUdGE/asJ78nWPxp4NlqajS1gPNWNV9AMX2NoGF6UQhAcsvpCJNMw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2a0d:3344:15ac:6900:7856:a4bc:3cee:1299] (unknown [IPv6:2a0d:3344:15ac:6900:7856:a4bc:3cee:1299]) (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: flo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dHPgY3dbPzKRd; Thu, 27 Nov 2025 18:13:29 +0000 (UTC) (envelope-from flo@FreeBSD.org) Message-ID: Date: Thu, 27 Nov 2025 19:13:23 +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 Subject: Re: looking for testers for if_rge - RTL8125/8126/8127 ethernet driver Content-Language: en-US To: Adrian Chadd , FreeBSD Net , freebsd-current References: From: Florian Smeets Autocrypt: addr=flo@FreeBSD.org; keydata= xsFNBFpyBwsBEADLq0c46orEtbMn4SptX+VJxR1wB4YwaErZme1bqF4nZHIhlRNET22HsHdQ doagaB4uACq0Rj5kHcu614ZnnNkLPyCxWQATx+cbdiFO4/hfT8tAvKnBtiy3awKJ5uGCNO2E zJwXW6KwdDA8XPRySqN8m1yPl+dW0Cls+/vO/QL/6+YLMupmEpSvFxRzAZTQuKyX4+xl+dYI d24JiPd1yfCuDNOY3+OZ3QBMT00u/699N8lUWRtiTwaQMwAOww8r/26YM6/SgcgFuLH2E/CV plY0sDvfoISlAj8agxdomNXfPjCMQ6w5yGZmA+huFpPCVBTi3on/SWgbQO7dLVpN4BNPuScP osCb/dsOg0S74zCClsIU3gdUGh9rwJY00/Ebid6V0R3c1Czwbg8LQedzlGDuXYXmzp6W2ujg r1cqbUD6lUWikUv2IMdCbb8MxYhHLi3GYUs5Xpi+W7vM6T45KbuMr7O/1SjtcGOlNeDvGNgj cDk20fOgPPZ+M6i9vX5Q2oI9HoYaeTiYNwILkBLVP/L40kTo5EkiQOt4OW6BMbylqXPOaQMW uGVbmhCJQpbx8Vo80s2yiBBVWkLkWQIcIm3KZlLldJqKEFpQBWLBE1eFFqboYgAWzFn73CaV 5tihobijMmmOV3a8cI1fI4kREyl3g+8bW+O0u3m3tuzVOpDpjwARAQABzSBGbG9yaWFuIFNt ZWV0cyA8ZmxvQEZyZWVCU0Qub3JnPsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAwIBAAIe AQIXgBYhBOyzaLh5CL+2kU1yae9bpNzVqfPABQJlmq1gBQkO64zlAAoJEO9bpNzVqfPAU3YQ ALit2AZO3MDHjKG7qT/43hSOnN3BoxRgRFz63N+bFR+tJlTE7k0SA8iephy97UKbf55wfQB4 v07q7kp1VckuJvorsU0ygCA2AnjNPRnGG3VyRfaJKBp22sGICDiMVe/c/SvCy/877A/tFVZj Z2rxTWNlT6i3In3YFae48OxCL8FfUFF+37tGmwj5PWi3lIpOKeuZLW0KHebXKCqpzIRcnjHO E7moQILrFsXvmay9JVYclNrDNIaePWuVlFNgFYMsF9+ixn3f7lTgprIyljS2F1fxpcBIR/Kj JFsjXl73IyZr3PxCBq8mpCi6ukD/58UFCvB9VRXUkAqm8k0eoBe61RlRoXrZlSmIq8qT0K97 tqFLpFVRylHnZEsjhxI6Drox+910LyF9rAZDS1GgDpyAd2qE7AgijcpFjpeYB480ZGgnRtEp 3v8MbGNhne7Og07hT1yB9DUoiM9gLxapLSujp2X6QWRONaLvv0Kz7BuCOHbMaol4YpjABd/4 3i5jnAsTBkBm6jsmEPhK69Vxsrkqs7E7OZOBnVdCR5HGZNq6Nss+dRXFHxGTyk+98ADLWl6M tQxZE8jYyxPzow5wNgkOoGrpTgQp0lDefI9pQhZFW77HZaBbbaffBAfISXWONmut7GVjb0oN xhW/OA/oQSiWYIP7c4JOWZ+apAZQtqNxYCWbzsFNBFpyBwsBEADR6zpub8nSv4o9c5A8i2c2 6IJOc4zIeqAK93B+KBmyRzy5chWUwlQWFMA+JIejVdbCrmTnl/2soMlYNUci7pZ87HOmI1zi MZaoakMBiPJPLLACKTEn9Nve/NQjRdhwuNgqyXh7VzTjQzTo7DLqMc4Gvcy0AoeIy05RP01C aOilQAVgVUbU1Ydme+6SrTe49jTxQR76eytFh31fk2J5bII4VANAAmZ1HR0tmEcwYQs80Hpb ncQc+eEvcW1KtZn2X1cfAGwBlxds8aOvJ77wACZ+PB4gUt3TIQhmCQ3WXY2ukHVBT4npopzs cJFMwqpisZvgI+1ErntUm2WaicZjCNXheDq5PwSSSO+GfxZyYGEeFJBIg9yfylKHEAiB93Wg dfvwl5YffSG+wD/kBripN75zR4e1QatxPlQIjOS1NAZoFvnHUTx5IsDO7A2tlZ1d1ar1e0Jq DCpxxc1AejZ/LhPompKeSfNT6+vJAzqu5C1t1JxpoNT1Km7Jwmk4piW9yQGFszlv/QmHD5Ww HSKovsB+zDqHi/jwPfQN5Fv/PNaxpnjmBc867DVS7XmvgCX17aeCzeYDlSDyKaLwjUlV1xCo Je2uL41Bs1Qc6x+z80/pOF1BEMDQgAnxmcRBMbZ8tfW477pmdK7/gBAB77Fkilx1FScyDY6n fVIqGhGyhgD5TwARAQABwsF8BBgBCgAmAhsMFiEE7LNouHkIv7aRTXJp71uk3NWp88AFAmWa rWAFCQ7rjOUACgkQ71uk3NWp88AgbBAAtHmL+mDSRzHYBgG9thI9cDr7M86uvtrAz1xjE8gl DEzqu+/XHNcg3KyoIjDzuipoPrpt73lLv+k67sfLY8YcaCq0WfP5BfJXOZcdpKzxQyaKI5h5 RDQsjEzpSESdDO2YCQypA9KRMJtI/VIJqxZglOp/Vh4aaF1t5Bi2NDNyAMHs8kToNRn56W51 72Lp9sJh9zrpA6DhJLhSWCc9tlzUWQUIdv0Y7Z5U5epfRuWTjYGSSc4kmve2eVBLIN+RMrRH kyVXIoj9AVwVoGMBPtHEYejBImOdV/oanW1EN0VNbQDAuRxhgrUfZR4KQY9GU7QcV5zn1zVh w0JLMIEqxFB9Q0TnMewTSXb482DM7cL6I3iYDoEjPkQOoYP3t9Y6bfF9h02LjVK5xNZ2qJ2r KNxGjV2BNk0NLfRBncVkX6BJWeQ1KBTEymd/8rD0vQprG9Uzqzth77sZoW6/983y1yMlsuer a6qqdH37m310/Gr3TQTCcGY3D8T27MUcLZXtw+MrbctKg8xe4CjHePODrQRrVuAuEIbHlOcs iQVw9UriY2SqHYsKgbVlIDdSZH3qbRrpLpQfjcJlQvWK4b2I1wQ69BDOjreN5IOYxhXRzgIX 86nrZ3CioiVFVBw4PoKMXo2pjbDavPMXZ8dUA7A6rmQPFHQ3S4HfIgxsh005YKJD2Zc= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 23.11.25 03:16, Adrian Chadd wrote: > hi! > > i've ported Kevin Lo's openbsd driver for these realtek chipsets to FreeBSD. > It works well enough for me to use on my laptop w/ RTL8125B / Killer E3000. > I'm now opening it up to others who are willing to build/run a kernel > module to test the driver out and report back. > This is great. Finally, an in tree driver for these very common NICs. The 1100.00 version of the net/realtek-re-kmod was just unreliable for me (constant hangs, no matter which options I turned off and on). I've only done light testing with the official 1101.00 driver. I was able to wedge it with less than a minute of iperf3, and the ifconfig down/up dance that was able to revive the interface with 1100.00 was not able to recover the interface. I ran if_rge on my NAS and did some testing. I haven't had one hang with this driver, even after pounding the network for hours. That's a big plus for me. Thanks. I was able to achieve close to 2.5Gb/s TX and close to 1Gb/s RX with iperf3 --bidir. CPU usage appears to be substantially higher than with the official Realtek driver. [intr{irq59: rge0}] goes to around 50% of one core, and [kernel{rge0 taskq thread}] hovers between 20-25% when running the above iperf3 tests. With the official 1101.00 driver, the only process using > 1% CPU is this one [kernel{re0 taskq}] and it is around 10% with the test mentioned above. The system is CPU: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics (3992.64-MHz K8-class CPU) rge0@pci0:1:0:0: class=0x020000 rev=0x05 hdr=0x00 vendor=0x10ec device=0x8125 subvendor=0x1f4c subdevice=0xb002 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8125 2.5GbE Controller' class = network subclass = ethernet bar [10] = type I/O Port, range 32, base 0xf000, size 256, enabled bar [18] = type Memory, range 64, base 0xdcb00000, size 65536, enabled bar [20] = type Memory, range 64, base 0xdcb10000, size 16384, enabled All tests were done with FreeBSD-kernel-generic-nodebug-16 kernels from the last couple of days. Florian From nobody Fri Nov 28 05:22:16 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 4dHhWM2QKnz6J4bp for ; Fri, 28 Nov 2025 05:22:23 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (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 4dHhWJ6PZdz3ZNB for ; Fri, 28 Nov 2025 05:22:20 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b="G/yDRqdi"; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id C1047240570; Fri, 28 Nov 2025 06:22:18 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 398B62403DB; Fri, 28 Nov 2025 06:22:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764307337; 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=t4m/awSiJRHBFPc0zwCGnvAL+mGmMs97YpGpPB0p0rU=; b=G/yDRqdipqg3MJ8usfqcwaDszqvhclCmEEoa5otcJYLUPdnbcX/CpDPBmT59tzgIYCrCyH vqkreaErU0ezzd75yIITtIrV/5/UekNfLEsRIdz1TBY4LQXtPxxtaqB79LH7LylsIFTSJ4 3Pj7nE02ZFWMkLMY0pnKpG+tUjYuOa1Rj0WcWbPrLN+pfUNU8sFKseNsN8OZEDLcarYzbZ BQeejM4w7g8MFuxuno5pfjxCXuzqBZeVmfXovw+IaFU93cGGxMzZBWNjuOlp4tLnVfONab NmikcZK9yqN5lPcjGRK10cQfyQTtBRQgP30DqLPyw3IHoGWXKuBz0ya/dszeiA== Received: from hermann (dynamic-2a02-3100-2d64-3302-10ac-6fd2-c671-be48.310.pool.telefonica.de [IPv6:2a02:3100:2d64:3302:10ac:6fd2:c671:be48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id D89DB2402EB; Fri, 28 Nov 2025 06:22:16 +0100 (CET) Date: Fri, 28 Nov 2025 06:22:16 +0100 From: FreeBSD User To: Warner Losh Cc: FreeBSD CURRENT Subject: Re: freezing on unmountin ext2fs USB device Message-ID: <20251128062140.120e8369@hermann> In-Reply-To: References: <20251123151439.361dd84c@thor.sb211.local> 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 X-Rspamd-UID: db1705 X-Rspamd-UID: 919526 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.58 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_HAM_SHORT(-0.48)[-0.479]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4dHhWJ6PZdz3ZNB On Tue, 25 Nov 2025 21:03:01 -0700 Warner Losh wrote: > On Sun, Nov 23, 2025 at 7:15=E2=80=AFAM A FreeBSD User > wrote: >=20 > > Hello, > > > > running FreeBSD 16.0-CURRENT #4 master-n282101-c8cf5a99f82b: Sun Nov 23 > > 13:56:23 CET > > 2025 amd64 I'm running into a serious problem when mounting an ext2fs > > formated USB Flash > > device (512GB). The devince contains files written by a Linux system, > > mounting the USB Flash > > via extended4fs, the size of the written datafiles is > 128GB. Deleting > > those files larger > > than some 20GB results in an I/O error reported by FReeBSD (# sudo rm > > /mnt/USB/filename). > > Unmounting the ext2fs after deletion (sudo umount /mnt) results in a to= tal > > freeze of the box. > > No crash, no core dump, nothing. I waited almost an hour hoping for > > recover. I have to > > physically switch off the box. > > > > I checked with other USB flash I have at hand, one Samsung 256 GB, ZFS - > > no problem, another > > 128GB, UFS, no problem and several much smaller (4 - 64GB) with FAT or = UFS > > filesystems, all no > > problem. > > > > I can not figure out whether it is the USB flash drive itself, the size= or > > the ext2fs itself > > causing the problem. > > > > Does anybody see similar problems or do have an tip to investigate with= out > > risking my box' > > health switching it on/off on failure? > > =20 >=20 > I've not seen this on the smaller tests I've been able to run. >=20 > So can you share the error messages that you get when you say you get I/O > errors? I'd like to see if this is due to an error in ext2fs or on the USB > drive. It's kinda sounding a little like the particular USB is triggering > some kind of issue that at the very least we should work around. Given th= at > it's not happening on all ext2fs drives you try to access, I'm leaning > towards the drive, but you never know. >=20 > Thanks Plugging the USB flash gives the following hardware information on the cons= ole: [...] ugen1.5: at usbus1 umass0 on uhub6 umass0: on usbus1 (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 = 00 00=20 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid co= mmand operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: Removable Direct Access SPC-4 SCSI device da4: Serial Number somer serial numbers da4: 400.000MB/s transfers da4: 475000MB (972800000 512 byte sectors) da4: quirks=3D0x2 [...] Trying to mount via: # mount -t ext2fs /dev/da4p1 /mnt/image [...] (da4:umass-sim0:0:0:0): got CAM status 0x444 (da4:umass-sim0:0:0:0): fatal error, failed to attach to device da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: s/n some serial numbers detached (da4:umass-sim0:0:0:0): Periph destroyed mount: /dev/da4p1: Device not configured [...] [...] # /compat/linux/sbin/fsck.ext4 /dev/da4p1 e2fsck 1.46.5 (30-Dec-2021) SINA was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Error writing file system info: Invalid argument XXXX: ***** FILE SYSTEM WAS MODIFIED ***** [...] detaching and attaching to another USB slot on the same (external) HUB: [...] ugen1.5: at usbus1 umass0 on uhub6 umass0: on usbus1 (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 = 00 00=20 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid co= mmand operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: Removable Direct Access SPC-4 SCSI device da4: Serial Number some serial numbers da4: 400.000MB/s transfers da4: 475000MB (972800000 512 byte sectors) da4: quirks=3D0x2 linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback fd=3D3, cmd=3D0x127= c ('\^R',124) is not implemented linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback fd= =3D3, cmd=3D0x125e ('\^R',94) is not implemented (da4:umass-sim0:0:0:0): got CAM status 0x444 (da4:umass-sim0:0:0:0): fatal error, failed to attach to device da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: s/n some serial numbers detached (da4:umass-sim0:0:0:0): Periph destroyed [...] I can not even mount the device on CURRENT (FreeBSD 16.0-CURRENT #1 master-n282217-34d66b0c96d5: Fri Nov 28 05:15:56 CET 2025 amd64). Package used for linux operation: emulators/linux-rl9 From nobody Fri Nov 28 06:08: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 4dHjY91qJwz6J8kH; Fri, 28 Nov 2025 06:09:01 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHjY85FB1z3ds2; Fri, 28 Nov 2025 06:09:00 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id BDE75240344; Fri, 28 Nov 2025 07:08:58 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 349C024016A; Fri, 28 Nov 2025 07:08:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764310137; 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=XGlP3yY3XubLtnLJbRwWqBG+b0FJSEvMyPD47DMj/x4=; b=hAC641fx7Y/3oHAXG4hVQxAAqEGmPqjmdilaKQa54c0NasmC3hnd1PpjsIZhAg/j0PNH8C T70gHU4B469sFMIWK+7z1j3SdU6UMgYH/1s4+zWp0PcI1kWhz4MoCunlLE3EGpudnXSVUH gpSQvT5pCVXQsJjiJ5G8RjxAD7zjRL3JN+PXSkwwUUDnQQ6camBwyZf9s0+qPBcjwhPuGW Z45yeJWEFOV0ZCdRkCtv/17mP5cdSF1Y7y4JskwTPywp/lO9XNT8kXULiFHg46sLz2A382 /0ilrbIpOT3qgxVT6bO9+MgR4xIpbRhY4VmtO3lYLftzu/ZIlzs3hROKQkQ2wQ== Received: from hermann (dynamic-2a02-3100-2d64-3302-10ac-6fd2-c671-be48.310.pool.telefonica.de [IPv6:2a02:3100:2d64:3302:10ac:6fd2:c671:be48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id E4DFB24002F; Fri, 28 Nov 2025 07:08:56 +0100 (CET) Date: Fri, 28 Nov 2025 07:08:56 +0100 From: FreeBSD User To: Cy Schubert Cc: Lars Tunkrans , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: FreeBSD/X11: Howto revive DisplayPort? Message-ID: <20251128070856.3fff9917@hermann> In-Reply-To: <20251127074747.2c250a85@slippy.cwsent.com> References: <20251126163059.3376d3e8@hermann> <77c2a2fb-ac5f-4b4a-98c6-660a39ee87b2@gmail.com> <20251127062631.5d8026c4@hermann> <20251127074747.2c250a85@slippy.cwsent.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-Transfer-Encoding: 7bit X-Rspamd-UID: 04bb39 X-Rspamd-UID: 18bc6b X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dHjY85FB1z3ds2 On Thu, 27 Nov 2025 07:47:47 -0800 Cy Schubert wrote: > One of HP 840 G5's docking station's DPs is connected to a VGA KVM > switch via a DP to VGA connector. Confirmed, this is an issue. > > The VGA KVM switch is also connected to my employer's HP 840 G9, also > via a DP to VGA connector. No problems there. Though that machine uses > the newer Thunderbolt docking station. Given that it's a newer machine > with a newer docking station I think the comparison only goes so far. In my specific case, the FreeBSD hosts are using DP, the KVM switch is a kind of hybrid (2x DP, 1x HDMI fpr usage of 3 monitors simultaneously with the computer) and the monitor itself is a 4k Lenovo, nothing fancy and/or expensive, just for doing conveniently my work at home. In my office, the equipment is similar, except the KVM switch, which is a DP only, more expensive type. In all cases, the host has a discrete nVidia GPU. > > Whether this is a FreeBSD or a UEFI BIOS problem isn't quite understood > by me. When booting the FreeBSD machine and if the KVM is not switched > to the FreeBSD machine, the text mode console will have the wrong > geometry. Even in single user the login prompt is far below the bottom > of the monitor. > > But once XDM has started it assumes a graphic geometry that fits the > laptop's screen, not the external monitor. I have a script that > disables the LVDS when the VGA is connected. Similar here, but worse when it comes to console only, as initially described. If the host booting and turning on the output for conosle is not switched to by the KVM - with monitor in ON state - the monitor stays dark, no chance to get it work without reboot of the FBSD box. Different story with X11/xdm running. To get an initial screen without further interaction, the KVM has to be switched to the host about to start. By the way, same issue with a LibreELEC/KODI driven host utilizing an Intel iGPU. But other than the issue with FBSD's console, with X11/xdm running and switching the KVM afterwards towards this DP output the FBSD box / X11 is running on, some could ssh onto the box and issue some xrandr command to refresh the output. I did this recently, sorry, I have the notes not at hand. But it is a kind of a labour and sometimes impossible to connect via ssh/reset DP output. As mentioned, Linux seems not to have those problems, at least with a RedHat based product I have to use for work - but that might be a commercial addition to the X11 server, I do not know, but I realize it works (at least for two of the scenarios I described). > > I suspect that this problem will require more tinkering (not by myself) > to better understand it. There are too many variables to say it's a > single issue. > > Another issue is, X segfaults on occasion on this machine. The segfault > always occurs when firefox is active. The screen goes blank as > drm-66-kmod (I think) is corrupted. (This happens maybe once or twice > a month, not enough to pull me away from other projects.) Are you > talking about this or the first issue above? The boxes at home are AM5 based newer systems utilizing recent Ryzen 9XXX CPUs with internal GPUs, one is using a recent nVidia GTX5XXX discrete GPU. I once used the drm-66-kmod framework to apply a high resoltution output from my server to the monitor, but using the console does not require microscopic small output, but I can state that the issue is quite the same as described before. I have not found any solution to revive a stuck DP-KVM-DP(Monitor) connection as described above with X11/xdm using the DRM-66 kmod output for the console (nor with the official nvidia kmod - speaking of nvidia, I always refer to the BLOB provided by most recent x11/nvidia-driver, x11/nvidia-kmod). I hoped for the lack of knowledge on my side when it comes to such issues, especially when the efi framebuffer for simple consoles is involved, but I realizie the problem might be bi-lateral one (both sides, hosts's DP and KVM/monitor's DP). Thank you very much for sharing. oh From nobody Fri Nov 28 06:33: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 4dHk682DTvz6JCCq for ; Fri, 28 Nov 2025 06:34:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 4dHk676DF0z3jXj for ; Fri, 28 Nov 2025 06:34:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-29568d93e87so15093035ad.2 for ; Thu, 27 Nov 2025 22:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1764311641; x=1764916441; 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=5u4sbO/WRQkX7KL0AbBZYAW+UxwMITNFRJ4TTWTUEBg=; b=KGMQwg5P2m1kKbU3gOmijEilukzp/4GI6lCQGvV168i3HxqYOVcBaA/xGxA7QHPb/o a2gMaGqXkwLN9XWu2c4uymoh3xyQOODSxORIqA5xAvJc6WdVZdpkR7DePavTh1MF+V2s VOHclqFijvNQQK7qc4feoug8yLF/bNFjb4QIK+Bq38toi/W0fTFZjgJz+kpdPwPu0PrF GQjMMgkL1VjYy0Eje0ANIFn17ND0cnINdfvEXjd69S2SrwT9pZR66TzrEBDwwxInAKjs DyZhwLLLl4fEmVPjxNZL4nLdfS8xNJe0laPy677r14y02Fztc0wOj526S1vve6W5I3zU 4lRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764311641; x=1764916441; 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=5u4sbO/WRQkX7KL0AbBZYAW+UxwMITNFRJ4TTWTUEBg=; b=HU2YWjQVCXhApmzLHDrtOPxaNyFskKZ1Qn3XoRG1CC/AzZiMH11q7RIV85BgxYKqNT 68IaycC3t5b4gDzxGozdF86yobKzrtM7H7m85w/sMNlO6hYedtxohX52aXBwECcH4b8H 8Aup0DZzBgmb1AgzI93hYvsGaRUYkVBKc89YgpOA9tngB9RRa1RlR90cmUsSBuXqW+/+ hwsMK+rediEcmTBYbv2Yjac7aZwVwDiD4s86Mry1IlWsalGtfcE2JqT3LSlnlrdofKZt WMY+aW5ZZsqt0kIvrubLbxw4cFkOIy8IFCXrgP2iTkJSmhjinLLPE7X52daXKdJYZHAc utQA== X-Gm-Message-State: AOJu0YzH1nmoUwZjY7tt3YOrlr+s/yVaPfgzglw53s9kB+9rBLD9uz8N kLCAfNJfunoYEZmv5CaEnEcmlATXN0bQuSGdsevWh020IOMKIAOB8th7OITLSfKpEjAwsiouQ12 2SRhU8nfExmkr4ehxnrBLkLCHInbygqmAOFEjKM7Mq/xdDLN9H2qw6AfDog== X-Gm-Gg: ASbGncuBY7rSliGNs9ANP3Y+gH4JX5hwazxikW3PhUYjNFu0SUpU3usxRypHFTM7a5D 7E4HqbOpFzzxUCl06fcyaS8E0QY6BT7KTP4T5kXiJ8T1BXJ2G4nuYImJTIjJL1kNhua8Glocy2X FndWKuPGysqRRpMhUzExB9kOxmdf8hSvpv+ftCQE1P58lf2Wf7FveqJ2T1Sscv6LBUzPq39WsGl SfZJcIrjursrPEoRjatbqFuKbLvKqde76yIBrc40xhHkMo3fThC/RqnJBB4Ptayg01Q0xE= X-Google-Smtp-Source: AGHT+IHTPjJsUGVSJs2gOU0p0zIb+2GU6ycv2FT4tLrChosY/nBSGhHJ2A2ketbivhc5s0U/GFPwydJ1ep7wS75c5+I= X-Received: by 2002:a17:902:d4d1:b0:246:e1b6:f9b0 with SMTP id d9443c01a7336-29baaf9abb7mr152896225ad.18.1764311641382; Thu, 27 Nov 2025 22:34: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: <20251123151439.361dd84c@thor.sb211.local> <20251128062140.120e8369@hermann> In-Reply-To: <20251128062140.120e8369@hermann> From: Warner Losh Date: Thu, 27 Nov 2025 23:33:50 -0700 X-Gm-Features: AWmQ_bnfroXG4CZC8HFQj9AjrEROQnyAcUHWjjhK6JE3ufs966ap9kA3ldGd780 Message-ID: Subject: Re: freezing on unmountin ext2fs USB device To: FreeBSD User Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000a86d030644a1d052" 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: 4dHk676DF0z3jXj --000000000000a86d030644a1d052 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 27, 2025, 10:22=E2=80=AFPM FreeBSD User wrote: > On Tue, 25 Nov 2025 21:03:01 -0700 > Warner Losh wrote: > > > On Sun, Nov 23, 2025 at 7:15=E2=80=AFAM A FreeBSD User > > wrote: > > > > > Hello, > > > > > > running FreeBSD 16.0-CURRENT #4 master-n282101-c8cf5a99f82b: Sun Nov = 23 > > > 13:56:23 CET > > > 2025 amd64 I'm running into a serious problem when mounting an ext2fs > > > formated USB Flash > > > device (512GB). The devince contains files written by a Linux system, > > > mounting the USB Flash > > > via extended4fs, the size of the written datafiles is > 128GB. Deleti= ng > > > those files larger > > > than some 20GB results in an I/O error reported by FReeBSD (# sudo rm > > > /mnt/USB/filename). > > > Unmounting the ext2fs after deletion (sudo umount /mnt) results in a > total > > > freeze of the box. > > > No crash, no core dump, nothing. I waited almost an hour hoping for > > > recover. I have to > > > physically switch off the box. > > > > > > I checked with other USB flash I have at hand, one Samsung 256 GB, ZF= S > - > > > no problem, another > > > 128GB, UFS, no problem and several much smaller (4 - 64GB) with FAT o= r > UFS > > > filesystems, all no > > > problem. > > > > > > I can not figure out whether it is the USB flash drive itself, the > size or > > > the ext2fs itself > > > causing the problem. > > > > > > Does anybody see similar problems or do have an tip to investigate > without > > > risking my box' > > > health switching it on/off on failure? > > > > > > > I've not seen this on the smaller tests I've been able to run. > > > > So can you share the error messages that you get when you say you get I= /O > > errors? I'd like to see if this is due to an error in ext2fs or on the > USB > > drive. It's kinda sounding a little like the particular USB is triggeri= ng > > some kind of issue that at the very least we should work around. Given > that > > it's not happening on all ext2fs drives you try to access, I'm leaning > > towards the drive, but you never know. > > > > Thanks > > Plugging the USB flash gives the following hardware information on the > console: > > [...] > ugen1.5: at usbus1 > umass0 on uhub6 > umass0: on usbus1 > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 1= 0 > 00 00 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > command > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > da4: Removable Direct Access SPC-4 SCSI device > da4: Serial Number somer serial numbers > da4: 400.000MB/s transfers > da4: 475000MB (972800000 512 byte sectors) > da4: quirks=3D0x2 > [...] > > Trying to mount via: # mount -t ext2fs /dev/da4p1 /mnt/image > > [...] > (da4:umass-sim0:0:0:0): got CAM status 0x444 > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > da4: s/n some serial numbers detached > (da4:umass-sim0:0:0:0): Periph destroyed > > mount: /dev/da4p1: Device not configured > This has the classic hallmarks of a drive that loses its mind on SYNCHRONIZE CACHE. Normally, we detect that automatically, but sometimes we don't. Let's see if this drive is suffering from that. These instructions are a bit long, but the shorter ones are harder to explain :). First, you'll need to find what this drive is. You'll need to use "usbconfig -v" to find the drive. Redirect that to a file, then search, you should find something akin to ugen0.13: at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5.0Gbps) pwr= =3DON (76mA) ugen0.13.0: umass1: The first line might not match, and the numbers will be different. But you'll need the vendor and product IDs from this drive. They are a few lines later and look akin to the following: ... idVendor =3D 0x090c idProduct =3D 0x1000 ... Now, remove the drive and type in the following (with your vendor and product replacing mine): usbconfig add_dev_quirk_vplh 0x090c 0x1000 0x0000 0xffff UQ_MSC_NO_SYNC_CACHE This will add a quirk to the usb quirk table. You should see NO_SYNC_CACHE show up in the da4 probe quirk report when you plug the drive back in. If that fixes it, please let me know. "Hang on close" or "Periph goes away on close" very often is due to this. umount will close the device. I may have additional questions for you to help me add a quirk or a heuristic to the code... I'm not yet sure, though, of the correlation to big files. It may be something else, or it may be this. Warner [...] > > [...] > # /compat/linux/sbin/fsck.ext4 /dev/da4p1 > e2fsck 1.46.5 (30-Dec-2021) > SINA was not cleanly unmounted, check forced. > Pass 1: Checking inodes, blocks, and sizes > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > Pass 4: Checking reference counts > Pass 5: Checking group summary information > Error writing file system info: Invalid argument > > XXXX: ***** FILE SYSTEM WAS MODIFIED ***** > > [...] > > detaching and attaching to another USB slot on the same (external) HUB: > > [...] > ugen1.5: at usbus1 > umass0 on uhub6 > umass0: on usbus1 > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 1= 0 > 00 00 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > command > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > da4: Removable Direct Access SPC-4 SCSI device > da4: Serial Number some serial numbers > da4: 400.000MB/s transfers > da4: 475000MB (972800000 512 byte sectors) > da4: quirks=3D0x2 > linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback fd=3D3, cmd=3D0x1= 27c > ('\^R',124) is > not implemented linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback > fd=3D3, cmd=3D0x125e > ('\^R',94) is not implemented (da4:umass-sim0:0:0:0): got CAM status 0x44= 4 > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > da4: s/n some serial numbers detached > (da4:umass-sim0:0:0:0): Periph destroyed > > [...] > > I can not even mount the device on CURRENT (FreeBSD 16.0-CURRENT #1 > master-n282217-34d66b0c96d5: Fri Nov 28 05:15:56 CET 2025 amd64). > > Package used for linux operation: emulators/linux-rl9 > --000000000000a86d030644a1d052 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 27, 2025, 10:22=E2=80=AFP= M FreeBSD User <freebsd@walstatt-de.de> wrote:
On Tue, 25 Nov 2025 21:03:01 -0700
Warner Losh <imp@bsdimp.com> wrote:

> On Sun, Nov 23, 2025 at 7:15=E2=80=AFAM A FreeBSD User <freebsd= @walstatt-de.de>
> wrote:
>
> > Hello,
> >
> > running FreeBSD 16.0-CURRENT #4 master-n282101-c8cf5a99f82b: Sun = Nov 23
> > 13:56:23 CET
> > 2025 amd64 I'm running into a serious problem when mounting a= n ext2fs
> > formated USB Flash
> > device (512GB). The devince contains files written by a Linux sys= tem,
> > mounting the USB Flash
> > via extended4fs, the size of the written datafiles is > 128GB.= Deleting
> > those files larger
> > than some 20GB results in an I/O error reported by FReeBSD (# sud= o rm
> > /mnt/USB/filename).
> > Unmounting the ext2fs after deletion (sudo umount /mnt) results i= n a total
> > freeze of the box.
> > No crash, no core dump, nothing. I waited almost an hour hoping f= or
> > recover. I have to
> > physically switch off the box.
> >
> > I checked with other USB flash I have at hand, one Samsung 256 GB= , ZFS -
> > no problem, another
> > 128GB, UFS, no problem and several much smaller (4 - 64GB) with F= AT or UFS
> > filesystems, all no
> > problem.
> >
> > I can not figure out whether it is the USB flash drive itself, th= e size or
> > the ext2fs itself
> > causing the problem.
> >
> > Does anybody see similar problems or do have an tip to investigat= e without
> > risking my box'
> > health switching it on/off on failure?
> >=C2=A0
>
> I've not seen this on the smaller tests I've been able to run.=
>
> So can you share the error messages that you get when you say you get = I/O
> errors? I'd like to see if this is due to an error in ext2fs or on= the USB
> drive. It's kinda sounding a little like the particular USB is tri= ggering
> some kind of issue that at the very least we should work around. Given= that
> it's not happening on all ext2fs drives you try to access, I'm= leaning
> towards the drive, but you never know.
>
> Thanks

Plugging the USB flash gives the following hardware information on the cons= ole:

[...]
ugen1.5: <ASolid USB> at usbus1
umass0 on uhub6
umass0: <ASolid USB, class 0/0, rev 3.20/1.10, addr 4> on usbus1
(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 = 00 00
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid co= mmand
operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error
da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
da4: <ASolid USB > Removable Direct Access SPC-4 SCSI device
da4: Serial Number somer serial numbers
da4: 400.000MB/s transfers
da4: 475000MB (972800000 512 byte sectors)
da4: quirks=3D0x2<NO_6_BYTE>
[...]

Trying to mount via:=C2=A0 # mount -t ext2fs /dev/da4p1 /mnt/image

[...]
(da4:umass-sim0:0:0:0): got CAM status 0x444
(da4:umass-sim0:0:0:0): fatal error, failed to attach to device
da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
da4: <ASolid USB >=C2=A0 s/n some serial numbers=C2=A0 detached
(da4:umass-sim0:0:0:0): Periph destroyed

mount: /dev/da4p1: Device not configured

This has the classic hallmarks of a= drive that loses its mind on SYNCHRONIZE CACHE. Normally, we detect that a= utomatically, but sometimes we don't. Let's see if this drive is su= ffering from that. These instructions are a bit long, but the shorter ones = are harder to explain :).

First, you&= #39;ll need to find what this drive is. You'll need to use "usbcon= fig -v" to find the drive. Redirect that to a file, then search, you s= hould find something akin to

ugen0.13: <Flash D= rive Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)> at= usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5.0Gbps) pwr=3DON (76mA)
ugen0.1= 3.0: umass1: <ASolid USB, class 0/0, rev 3.00/11.00, addr 12>

The first line might not match, and the = numbers will be different. But you'll need the vendor and product IDs f= rom this drive. They are a few lines later and look akin to the following:<= /div>
...
=C2=A0 idVendor =3D 0x090c
=C2=A0 idProduct =3D = 0x1000
...

Now, remove the drive and type in the following (with your vendor and prod= uct replacing mine):

usbconfig=C2=A0add_dev_quirk_= vplh 0x090c 0x1000 0x0000 0xffff=C2=A0UQ_MSC_NO_SYNC_CACHE

This will add a quirk to the usb quirk table. You should see NO_SY= NC_CACHE show up in the da4 probe quirk report when you plug the drive back= in.

If that fixes it, please let me know. "H= ang on close" or "Periph goes away on close" very often is d= ue to this. umount will close the device. I may have additional questions f= or you to help me add a quirk or a heuristic to the code... I'm not yet= sure, though, of the correlation to big files. It may be something else, o= r it may be this.

Warner
[...]

[...]
# /compat/linux/sbin/fsck.ext4 /dev/da4p1
e2fsck 1.46.5 (30-Dec-2021)
SINA was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Error writing file system info: Invalid argument

XXXX: ***** FILE SYSTEM WAS MODIFIED *****

[...]

detaching and attaching to another USB slot on the same (external) HUB:

[...]
ugen1.5: <ASolid USB> at usbus1
umass0 on uhub6
umass0: <ASolid USB, class 0/0, rev 3.20/1.10, addr 6> on usbus1
(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 = 00 00
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid co= mmand
operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error
da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
da4: <ASolid USB > Removable Direct Access SPC-4 SCSI device
da4: Serial Number some serial numbers
da4: 400.000MB/s transfers
da4: 475000MB (972800000 512 byte sectors)
da4: quirks=3D0x2<NO_6_BYTE>
linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback fd=3D3, cmd=3D0x127= c ('\^R',124) is
not implemented linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback fd= =3D3, cmd=3D0x125e
('\^R',94) is not implemented (da4:umass-sim0:0:0:0): got CAM statu= s 0x444
(da4:umass-sim0:0:0:0): fatal error, failed to attach to device
da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
da4: <ASolid USB >=C2=A0 s/n some serial numbers detached
(da4:umass-sim0:0:0:0): Periph destroyed

[...]

I can not even mount the device on CURRENT (FreeBSD 16.0-CURRENT #1
master-n282217-34d66b0c96d5: Fri Nov 28 05:15:56 CET 2025 amd64).

Package used for linux operation: emulators/linux-rl9
--000000000000a86d030644a1d052-- From nobody Fri Nov 28 06:37: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 4dHkBP0jpvz6JCh6 for ; Fri, 28 Nov 2025 06:37:49 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (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 "plan-b.pwste.edu.pl", Issuer "GEANT TLS ECC 1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHkBM4WH8z3kd0 for ; Fri, 28 Nov 2025 06:37:47 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=vqxTiWLL; dmarc=pass (policy=quarantine) header.from=plan-b.pwste.edu.pl; spf=pass (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl designates 2001:678:618::40 as permitted sender) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 5AS6bLx1027628 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 28 Nov 2025 07:37:34 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1764311854; bh=c5iikAbj9aXWEZQOxqDng71hEPXMEc0CuHx28juQOns=; h=Date:Subject:To:References:From:In-Reply-To; b=vqxTiWLL2CPxl+iSB3AOGFVmu6dEPaTkGe6OtPPPYS47VDSb3vYgAy/+QUts4rYo/ DBPb1ogFXWwdmjE2D5J7UFNAeCPOJiRwwG+gLgkHPg7Wa2i81hRSkwJQhF3Dv80T/w Liyhr1CFmtDR5ktxuHTNiUg5PZZiTQEKxxKuqje8yx8UsRcqPb09Ym2K4B2ETTcWp2 yvlyPdqenXDPa+w+0h+1mi6XCK66WxWBAz2IHfl3wclWpMOqVt4oEXqRqoboKaspYL 2fRgAhU3XOtthDaGKJ/NP8HTe3gZK1Bope1TfozYHRyiI0wqJ4yLwgWYme58QeWObq sxgMdE9nTEzHA== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: Date: Fri, 28 Nov 2025 07:37:20 +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 Subject: Re: FreeBSD/X11: Howto revive DisplayPort? To: freebsd-current@freebsd.org References: <20251126163059.3376d3e8@hermann> <77c2a2fb-ac5f-4b4a-98c6-660a39ee87b2@gmail.com> <20251127062631.5d8026c4@hermann> <20251127074747.2c250a85@slippy.cwsent.com> <20251128070856.3fff9917@hermann> Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: <20251128070856.3fff9917@hermann> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+] X-Rspamd-Queue-Id: 4dHkBM4WH8z3kd0 W dniu 28.11.2025 o 07:08, FreeBSD User pisze: > As mentioned, Linux seems not to have those problems, at least with a RedHat based > product I have to use for work - but that might be a commercial addition to the X11 > server, I do not know, but I realize it works (at least for two of the scenarios I > described). To cheer you up, I can say that on the Linux system (a Debian-based Linux distribution with an older Radeon GPU), I experience the same issue: on one of my PCs, the monitor connected via DisplayPort isn’t detected unless I power it on manually, for example after a power outage. Cheers -- Marek Zarychta From nobody Fri Nov 28 07:26:30 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 4dHlGh6xmQz6JJ46 for ; Fri, 28 Nov 2025 07:26:36 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4dHlGg5hL2z3qTv for ; Fri, 28 Nov 2025 07:26:35 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=R6Tt8a9S; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.60 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 8478D2404B5 for ; Fri, 28 Nov 2025 08:26:33 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id F31C1240206 for ; Fri, 28 Nov 2025 08:26:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764314792; 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; bh=v/AEaxHPC9n+OoY0YCJActV0v3nloH+E1Frs27ff8PY=; b=R6Tt8a9Smq0WyUnfOypNWygn5h2Z4ztqkHkRiH/NZwZVpH+EWwutd0Z4ZG3/pn8jo7ydBZ blsl0pIMX5kluy4aYLvRf5cZ1Di6sJECnuoZQMMkNYBz1CfWjMYkXudqUmdhG98emO+SYT lejGoeErvcB66VL+FXkRunXGKsyYg7chFmVeSa5hG246iE3xqmxHTG5sxKd54T/H4xqDDK K6TRZEUyv8xfxsmYPe5lT8HSJSCpMdNFobB1XOcfd1Q6bHkh1/ZOZ8irh8lP/CVykYSO5P CxBZwbzdNp+0LdaRvhE3FNvZZsA8mmZVpmB42KLjf4V8e+/VKDAXv2NGylsOcg== Received: from hermann (dynamic-2a02-3100-2d64-3302-7d41-fb4c-014d-2107.310.pool.telefonica.de [IPv6:2a02:3100:2d64:3302:7d41:fb4c:14d:2107]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id B1CF6240182 for ; Fri, 28 Nov 2025 08:26:31 +0100 (CET) Date: Fri, 28 Nov 2025 08:26:30 +0100 From: FreeBSD User To: FreeBSD CURRENT Subject: 15-STABLE: dhclient fails on em0 (Lenovo T580) Message-ID: <20251128082630.3dbea678@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 462149 X-Rspamd-UID: 5cc866 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.27 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; NEURAL_HAM_SHORT(-0.17)[-0.168]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.60:from]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; BLOCKLISTDE_FAIL(0.00)[85.220.129.60:server fail,85.220.129.52:server fail,2a02:3100:2d64:3302:7d41:fb4c:14d:2107:server fail]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4dHlGg5hL2z3qTv I recently switched from FreeBSD 14-STABLE to 15-STABLE (after branching of 16-CURRENT) on my working laptop, physically a Lenovo T580. Its LAN NIC FreeBSD recognizes as em0 (see below). System is at: 15.0-STABLE #16 stable/15-n281349-b903f27e171b: Fri Nov 28 05:20:32 CET 2025 amd64. Kernel config: GENERIC. Configuration has been setup and renewed acording to changes, consider the system as a fresh install. Problem: em0 never gets an IPv4 via DHCP on startup (init process via rc.conf). Configured in /etc/src.conf: [... WORKAROUND ...] netwait_enable="NO" netwait_if="em0" [...] and on a regular basis: [...] ifconfig_em0="DHCP" ifconfig_em0_ipv6="inet6 accept_rtadv -ifdisabled nud -no_radr auto_linklocal" [...] Very strange: after a final boot up, its very easy to require and achive an IPv4 with dhclient em0 I'm out of ideas ... ==== pciconf: [...] em0@pci0:0:31:6: class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x15d8 subvendor=0x17aa subdevice=0x225a vendor = 'Intel Corporation' device = 'Ethernet Connection (4) I219-V' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xe8200000, size 131072, enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP [...] dmesg: ichsmb0: port 0xefa0-0xefbf mem 0xe8253000-0xe82530ff at device 31.4 on pci0 em0: mem 0xe8200000-0xe821ffff at device 31.6 on pci0 em0: EEPROM V0.1-3 em0: Using 1024 TX descriptors and 1024 RX descriptors em0: Using an MSI interrupt em0: Ethernet address: 48:2a:e3:3a:cf:52 em0: netmap queues/slots: TX 1/1024, RX 1/1024 From nobody Fri Nov 28 07:35: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 4dHlTW6yMVz6JK5F for ; Fri, 28 Nov 2025 07:35:59 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 4dHlTW2TpCz3rfV for ; Fri, 28 Nov 2025 07:35:59 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=iwxh5VOF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::336 as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-477a219dbcaso12725915e9.3 for ; Thu, 27 Nov 2025 23:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764315356; x=1764920156; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=tb0UKBwGV99zTUvGe8YQc+4K1XjxdCYM2byqWfnaf+4=; b=iwxh5VOFc09ArAaQ2v6lB34ecxuMh5uRdblyIgVMgMS+fqpdXxf/7464U049NlJfcL AQfo5MPqkOZhQIlkTJ0m6l9Oqf1/kfGzodI+5i75AfRPaWlKJufDOA7cPDclhqaDj32j wOtddwezhMqoqzZdzdlX/EAODksWNx4jWbnUHGpo+57e4teGqQ5gStwlT9Zdn1CkxdOr uiDt89Bt+NbewHn6P13S5Cq36ELAClMy3e4I28e5Bcc/igvNZsJ0RvzSuWAxbHf5nUTL t4fHjIhGqJr7hKTtK87yGDsfPaTSKaH2utqPZ2+7XksfWS6eVTlZvm1HRInE9lAeM0Xy HdKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764315356; x=1764920156; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tb0UKBwGV99zTUvGe8YQc+4K1XjxdCYM2byqWfnaf+4=; b=OAgHrhucuesfh3ihnO0EHastjwIlUn7T6CQIXkO0Z78Y6X+R9Gf6aN7/vlWZ/dC1kQ 0At9Q5+XNIHumrUd6w3dvcB34tx029eYEpL+cdiIM9q/61uWtVciptAVZ8hlq7Yn69sz 4H4C2CJDeoWo2YzpD0Vzzh7OqA+yQps600xjMJ/cODeRdNyZtt1p59iIcE4g4XuS3IBd yMVJANFWrprB9AEWGCXxLDprQnveAOyhRQS+GWHfHi4JLaPtRqXzGa6BJkKFKIJcGNH+ g8BNi4o8m3VyuDgDv2+QpdxU2F7yKbHyohw/Ycqtwn1cGJxwSupYBhy3kIi+y+DGWLkK qNrA== X-Gm-Message-State: AOJu0YyCkkIoOE0Q6Mh201mi2tG+Zhl7XNMEHWSGwbWPAp6Qz9AI0lVt Z8Uj52PkxhIglIXT3eSRqA6cIomI6x8yoGcrlRjjC3W27baM/iXlhGw0QrZpmQ== X-Gm-Gg: ASbGncv9TUy4Qrmx2f/pScUNdJUo7hUI0K4GYCKMg/VZ349i84Y/b9K5xKkwvTy125/ cvr8P+wMHYGcDwpyrNNp6Fjt3QupeLE+R9N9hPHOw/jmRPPv5Lh/xtxITj9vUGzelm7C/yFkXfp CnwkvyqFEVHOLkbtnS84aoeICpCY289/qHAQwcMREdfJJh16arEsqJ9NcbOO+BnKH7feL8gNPVI Yd+TNqgs4nZQvzT0UUxXh+X+/p26nA7pI0FmlM96oaXMBVx0Y03vkWLNRVoKcA+qym4mJeo1Zoj q/k2BggBxZML2zJE8US7DpOKwCIv8yzPBZZ6k/fXmdCh7NW4Ly5GRPoDGEbyn7I0AH2Alzc1tDa w04+86CNzU/Dcn/FqxNZztobauFGah6ighpWcsLf83NFKR9CQMrpd0aCZlwBRzmPO0KBDjqBsph GUePhHZzJZJir6YTVorDol8auiKYLNSDoSOJOSqx6us4Gyida43u3+Y+wMV/c= X-Google-Smtp-Source: AGHT+IHTNLTnCvvdCU8eThdrHhiI9+j4qAVXKLu/29PNIE1TRzlQkL0xIQaxFyTL0jXhopYdHT44bA== X-Received: by 2002:a05:600c:1994:b0:46f:c55a:5a8d with SMTP id 5b1f17b1804b1-477c0176437mr276291255e9.4.1764315355922; Thu, 27 Nov 2025 23:35:55 -0800 (PST) Received: from ?IPV6:2a01:cb15:8545:7700:62cf:84ff:fe81:caec? ([2a01:cb15:8545:7700:62cf:84ff:fe81:caec]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4790adc8bbbsm142768635e9.3.2025.11.27.23.35.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Nov 2025 23:35:55 -0800 (PST) Message-ID: <950fe459-217b-4066-99d8-1fa3247d0d84@gmail.com> Date: Fri, 28 Nov 2025 08:35:54 +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 Subject: Re: FreeBSD/X11: Howto revive DisplayPort? To: freebsd-current@freebsd.org References: <20251126163059.3376d3e8@hermann> <77c2a2fb-ac5f-4b4a-98c6-660a39ee87b2@gmail.com> Content-Language: en-US From: Paul Floyd In-Reply-To: <77c2a2fb-ac5f-4b4a-98c6-660a39ee87b2@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: - X-Spamd-Result: default: False [-1.01 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.99)[0.987]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from] X-Rspamd-Queue-Id: 4dHlTW2TpCz3rfV On 2025-11-26 22:31, Lars Tunkrans wrote: > HI > >    Yes I  have  same experience. > >    I beleive its because the  DDC/ EDID   info sent from screen over  > the  connection cable >    is  lost  if  the  KVM  and screen is not connected to the computer > at start up. >     If I make sure that  the screen is attached to  the computer when > the computer powers up >      a  Usable resoultion/timing is selected by the graphics card. > I don't think that this is limited to DP either. I use a ugreen 4port HDMI KVM for Mac mini/workstation/old workstation/R Pi. Sometimes if I boot a device and forget to switch the KVM to the correct port then I get a black screen and have to ssh to whatever to reboot it. A+ Paul From nobody Fri Nov 28 09:16: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 4dHnjP1Pj1z6JVBd for ; Fri, 28 Nov 2025 09:16:25 +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 4dHnjM4fBHz42Mc for ; Fri, 28 Nov 2025 09:16:23 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none 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 4dHnjD15rtz1Y5; Fri, 28 Nov 2025 10:16:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1764321376; 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=9frFQJWfBsaSbNC21L9Ga+DLprVUBMEgR5y1NKxuzLY=; b=CXpGvdi00G8XYRBgw/WwZwY3QA15Cp3JVkYieIhgXaUuWagSE2BCCTUYvfQUlnT8ocNnra i+2LY+cFS9J/NLGXuEyPEAdGxELEFm2UPE5CJO9YisKapCIFQz4L6s5nHHLLvjClojMrTC M4oSdRbN113cAd6sxDnchEsvmbm2MPLj0Do0y9OBgTOAdr8ZwHNuL7bJc53yGPyrasBSyc JPYflmaRWUveCFipUR9NueKbqu8A3YkdKgF7gneslH4rhJHmPPLB02EFgrQvP/N9F4++cN dNxQXT2Du/PMOCFu5MfRuJS5XNOEIJw1ujIM8ZCsaZ/VRkR/UYJBa7PaV+M6jg== Received: from crmpreview8.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview8.colo2.realworks.nl (Postfix) with ESMTP id 0AD312C081E; Fri, 28 Nov 2025 10:16:15 +0100 (CET) Date: Fri, 28 Nov 2025 10:16:15 +0100 (CET) From: Ronald Klop To: FreeBSD User Cc: FreeBSD CURRENT Message-ID: <817794595.3413.1764321375872@localhost> In-Reply-To: <20251128082630.3dbea678@hermann> References: <20251128082630.3dbea678@hermann> Subject: Re: 15-STABLE: dhclient fails on em0 (Lenovo T580) 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_3412_1623196129.1764321375474" X-Mailer: Realworks (775.24) 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, 28 Nov 2025 10:16:15 +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 [-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: 4dHnjM4fBHz42Mc ------=_Part_3412_1623196129.1764321375474 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It might be a typo in your mail, but it might also be the cause of your issue. This config needs to be in /etc/rc.conf, not in /etc/src.conf as you state in your mail. Regards, Ronald. Van: FreeBSD User Datum: vrijdag, 28 november 2025 08:26 Aan: FreeBSD CURRENT Onderwerp: 15-STABLE: dhclient fails on em0 (Lenovo T580) > > I recently switched from FreeBSD 14-STABLE to 15-STABLE (after branching of 16-CURRENT) > on my working laptop, physically a Lenovo T580. Its LAN NIC FreeBSD recognizes as em0 > (see below). System is at: 15.0-STABLE #16 stable/15-n281349-b903f27e171b: Fri Nov 28 > 05:20:32 CET 2025 amd64. Kernel config: GENERIC. > Configuration has been setup and renewed acording to changes, consider the system as a > fresh install. > > Problem: em0 never gets an IPv4 via DHCP on startup (init process via rc.conf). > > Configured in /etc/src.conf: > [... WORKAROUND ...] > netwait_enable="NO" > netwait_if="em0" > [...] > > and on a regular basis: > [...] > ifconfig_em0="DHCP" > ifconfig_em0_ipv6="inet6 accept_rtadv -ifdisabled nud -no_radr auto_linklocal" > [...] > > Very strange: after a final boot up, its very easy to require and achive an IPv4 with > > dhclient em0 > > I'm out of ideas ... > > > > > > ==== > pciconf: > [...] > em0@pci0:0:31:6: class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x15d8 > subvendor=0x17aa subdevice=0x225a vendor = 'Intel Corporation' > device = 'Ethernet Connection (4) I219-V' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xe8200000, size 131072, enabled > cap 01[c8] = powerspec 3 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 13[e0] = PCI Advanced Features: FLR TP > > [...] > > dmesg: > ichsmb0: port 0xefa0-0xefbf mem > 0xe8253000-0xe82530ff at device 31.4 on pci0 em0: mem > 0xe8200000-0xe821ffff at device 31.6 on pci0 em0: EEPROM V0.1-3 > em0: Using 1024 TX descriptors and 1024 RX descriptors > em0: Using an MSI interrupt > em0: Ethernet address: 48:2a:e3:3a:cf:52 > em0: netmap queues/slots: TX 1/1024, RX 1/1024 > > > > > ------=_Part_3412_1623196129.1764321375474 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
It might be a typo in your mail, but it might also be the cause of your issue.
This config needs to be in /etc/rc.conf, not in /etc/src.conf as you state in your mail.

Regards,
Ronald.

 

Van: FreeBSD User <freebsd@walstatt-de.de>
Datum: vrijdag, 28 november 2025 08:26
Aan: FreeBSD CURRENT <freebsd-current@freebsd.org>
Onderwerp: 15-STABLE: dhclient fails on em0 (Lenovo T580)

I recently switched from FreeBSD 14-STABLE to 15-STABLE (after branching of 16-CURRENT)
on my working laptop, physically a Lenovo T580. Its LAN NIC FreeBSD recognizes as em0
(see below). System is at: 15.0-STABLE #16 stable/15-n281349-b903f27e171b: Fri Nov 28
05:20:32 CET 2025 amd64. Kernel config: GENERIC.
Configuration has been setup and renewed acording to changes, consider the system as a
fresh install.

Problem: em0 never gets an IPv4 via DHCP on startup (init process via rc.conf).

Configured in /etc/src.conf:
[... WORKAROUND ...]
netwait_enable="NO"
netwait_if="em0"
[...]

and on a regular basis:
[...]
ifconfig_em0="DHCP"
ifconfig_em0_ipv6="inet6 accept_rtadv -ifdisabled nud -no_radr auto_linklocal"
[...]

Very strange: after a final boot up, its very easy to require and achive an IPv4 with

dhclient em0

I'm out of ideas ...





====
pciconf:
[...]
em0@pci0:0:31:6:        class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x15d8
subvendor=0x17aa subdevice=0x225a vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection (4) I219-V'
    class      = network
    subclass   = ethernet
    bar   [10] = type Memory, range 32, base 0xe8200000, size 131072, enabled
    cap 01[c8] = powerspec 3  supports D0 D3  current D0
    cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
    cap 13[e0] = PCI Advanced Features: FLR TP

[...]

dmesg:
ichsmb0: <Intel Sunrise Point-LP SMBus controller> port 0xefa0-0xefbf mem
0xe8253000-0xe82530ff at device 31.4 on pci0 em0: <Intel(R) I219-V SPT(4)> mem
0xe8200000-0xe821ffff at device 31.6 on pci0 em0: EEPROM V0.1-3
em0: Using 1024 TX descriptors and 1024 RX descriptors
em0: Using an MSI interrupt
em0: Ethernet address: 48:2a:e3:3a:cf:52
em0: netmap queues/slots: TX 1/1024, RX 1/1024

 

  ------=_Part_3412_1623196129.1764321375474-- From nobody Fri Nov 28 09:50:16 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 4dHpSf4LWGz6JYTq for ; Fri, 28 Nov 2025 09:50:26 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dHpSf3bZqz47TQ for ; Fri, 28 Nov 2025 09:50:26 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 863CA240278; Fri, 28 Nov 2025 10:50:19 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id F320524046B; Fri, 28 Nov 2025 10:50:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764323418; 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=hC+bJA+XQhjy7ihEUhR6mwk0NwGdGcI9fTYD0z1rS6o=; b=jmbf0d4MPyXXN65EXI7YnY/p+r7AS+HYzpXCTihf9tOsr8NhPZx+1s0Po7CgTeRup1cADS 8la4bcjKMEX7xcjZkevbhLYdNTrFi6MsvOyYV8MfC0mkBqJHI7qQQM1o41p29Z8wLTVtoT 8ld+AjFRvIcpuGK667kYfb9xCuyEDuwuS4qdWwyPAj4PhVOq43OwU90qog7SpfyDSizQNF AxiF7+EWbmwUlJgOVcxmvLriyzX+A7fOw/fU9rKe1XoaZfFK5y7TC2tiOXRM513KIt79Af MfXlh5zhenn7Yxo0r61BHCZVQwtZz2cgiCQtoWmPEXh1aaWw04KCnkIBLG79xA== Received: from hermann (dynamic-2a02-3100-2d64-3302-1bfd-4657-cf65-5231.310.pool.telefonica.de [IPv6:2a02:3100:2d64:3302:1bfd:4657:cf65:5231]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id C58532402EB; Fri, 28 Nov 2025 10:50:17 +0100 (CET) Date: Fri, 28 Nov 2025 10:50:16 +0100 From: FreeBSD User To: Ronald Klop Cc: FreeBSD CURRENT Subject: Re: 15-STABLE: dhclient fails on em0 (Lenovo T580) Message-ID: <20251128105016.28b5562a@hermann> In-Reply-To: <817794595.3413.1764321375872@localhost> References: <20251128082630.3dbea678@hermann> <817794595.3413.1764321375872@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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 3d5694 X-Rspamd-UID: eef453 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dHpSf3bZqz47TQ On Fri, 28 Nov 2025 10:16:15 +0100 (CET) Ronald Klop wrote: > It might be a typo in your mail, but it might also be the cause of your issue. > This config needs to be in /etc/rc.conf, not in /etc/src.conf as you state in your mail. > > Regards, > Ronald. Sorry, a typo. > > > Van: FreeBSD User > Datum: vrijdag, 28 november 2025 08:26 > Aan: FreeBSD CURRENT > Onderwerp: 15-STABLE: dhclient fails on em0 (Lenovo T580) > > > > I recently switched from FreeBSD 14-STABLE to 15-STABLE (after branching of > > 16-CURRENT) on my working laptop, physically a Lenovo T580. Its LAN NIC FreeBSD > > recognizes as em0 (see below). System is at: 15.0-STABLE #16 > > stable/15-n281349-b903f27e171b: Fri Nov 28 05:20:32 CET 2025 amd64. Kernel config: > > GENERIC. Configuration has been setup and renewed acording to changes, consider the > > system as a fresh install. > > > > Problem: em0 never gets an IPv4 via DHCP on startup (init process via rc.conf). > > > > Configured in /etc/src.conf: > > [... WORKAROUND ...] > > netwait_enable="NO" > > netwait_if="em0" > > [...] > > > > and on a regular basis: > > [...] > > ifconfig_em0="DHCP" > > ifconfig_em0_ipv6="inet6 accept_rtadv -ifdisabled nud -no_radr auto_linklocal" > > [...] > > > > Very strange: after a final boot up, its very easy to require and achive an IPv4 with > > > > dhclient em0 > > > > I'm out of ideas ... > > > > > > > > > > > > ==== > > pciconf: > > [...] > > em0@pci0:0:31:6: class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x15d8 > > subvendor=0x17aa subdevice=0x225a vendor = 'Intel Corporation' > > device = 'Ethernet Connection (4) I219-V' > > class = network > > subclass = ethernet > > bar [10] = type Memory, range 32, base 0xe8200000, size 131072, enabled > > cap 01[c8] = powerspec 3 supports D0 D3 current D0 > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > cap 13[e0] = PCI Advanced Features: FLR TP > > > > [...] > > > > dmesg: > > ichsmb0: port 0xefa0-0xefbf mem > > 0xe8253000-0xe82530ff at device 31.4 on pci0 em0: mem > > 0xe8200000-0xe821ffff at device 31.6 on pci0 em0: EEPROM V0.1-3 > > em0: Using 1024 TX descriptors and 1024 RX descriptors > > em0: Using an MSI interrupt > > em0: Ethernet address: 48:2a:e3:3a:cf:52 > > em0: netmap queues/slots: TX 1/1024, RX 1/1024 > > > > > > > > > > > > From nobody Fri Nov 28 09:56: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 4dHpbH55C4z6JZ2M for ; Fri, 28 Nov 2025 09:56:11 +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 4dHpbG5HJvz49qB for ; Fri, 28 Nov 2025 09:56:10 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmpreview5.colo2.realworks.nl [10.2.52.35]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4dHpbD5fYlzb3; Fri, 28 Nov 2025 10:56:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1764323768; 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=1qHXDSL2TW5qs/qaA7ioqa0qhAVQ2/phaT3DjLp4+oM=; b=x8tCk+eYYHMFuiZYAY6gh3A0oZ1NG/Au7egfXwoAGhHVitsKYRuRFEupZ6MKBYqCLN3Mrk aOwX8y36xk7Qw6CiV+oMIXHocht0y86rl7Hq2qfh4p28ZBU3n+Mk4wA5659OEH8WAL5rHp /Prnx0etU1gQo3GKixytLJhRWvuegEfWt3eptFmZh4AxCaXxKeCzGW5wVtcKpR/FOdgu3t KtJRzypXkmi+a/5PlFgap2f1zAlDlB2mJsFRrK83vNXT8EgQQW8qB4ONP2/XohbMgeAivW 1PSaYxdIp8jpQW8Y0Y5NjH7zfxyI4uc5158ZiBUrawR69H21kw7viLkB1A9S8g== Received: from crmpreview5.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview5.colo2.realworks.nl (Postfix) with ESMTP id B65EEC04DF; Fri, 28 Nov 2025 10:56:08 +0100 (CET) Date: Fri, 28 Nov 2025 10:56:08 +0100 (CET) From: Ronald Klop To: FreeBSD User Cc: FreeBSD CURRENT Message-ID: <636185594.3615.1764323768736@localhost> In-Reply-To: <20251128105016.28b5562a@hermann> References: <20251128082630.3dbea678@hermann> <817794595.3413.1764321375872@localhost> <20251128105016.28b5562a@hermann> Subject: Re: 15-STABLE: dhclient fails on em0 (Lenovo T580) 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_3614_1576089190.1764323768284" X-Mailer: Realworks (775.24) X-Originating-Host: from (83-81-212-149.cable.dynamic.v4.ziggo.nl [83.81.212.149]) by crmpreview5.colo2.realworks.nl [10.2.52.35] with HTTP; Fri, 28 Nov 2025 10:56:08 +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 [-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: 4dHpbG5HJvz49qB ------=_Part_3614_1576089190.1764323768284 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ok. Can you copy paste the console output of the booting system up until the login prompt? Or setup /var/log/console.log via /etc/syslog.conf and share that output. Regards, Ronald. Van: FreeBSD User Datum: vrijdag, 28 november 2025 10:50 Aan: Ronald Klop CC: FreeBSD CURRENT Onderwerp: Re: 15-STABLE: dhclient fails on em0 (Lenovo T580) > > On Fri, 28 Nov 2025 10:16:15 +0100 (CET) > Ronald Klop wrote: > > > It might be a typo in your mail, but it might also be the cause of your issue. > > This config needs to be in /etc/rc.conf, not in /etc/src.conf as you state in your mail. > > > > Regards, > > Ronald. > > Sorry, a typo. > > > > > > > Van: FreeBSD User > > Datum: vrijdag, 28 november 2025 08:26 > > Aan: FreeBSD CURRENT > > Onderwerp: 15-STABLE: dhclient fails on em0 (Lenovo T580) > > > > > > I recently switched from FreeBSD 14-STABLE to 15-STABLE (after branching of > > > 16-CURRENT) on my working laptop, physically a Lenovo T580. Its LAN NIC FreeBSD > > > recognizes as em0 (see below). System is at: 15.0-STABLE #16 > > > stable/15-n281349-b903f27e171b: Fri Nov 28 05:20:32 CET 2025 amd64. Kernel config: > > > GENERIC. Configuration has been setup and renewed acording to changes, consider the > > > system as a fresh install. > > > > > > Problem: em0 never gets an IPv4 via DHCP on startup (init process via rc.conf). > > > > > > Configured in /etc/src.conf: > > > [... WORKAROUND ...] > > > netwait_enable="NO" > > > netwait_if="em0" > > > [...] > > > > > > and on a regular basis: > > > [...] > > > ifconfig_em0="DHCP" > > > ifconfig_em0_ipv6="inet6 accept_rtadv -ifdisabled nud -no_radr auto_linklocal" > > > [...] > > > > > > Very strange: after a final boot up, its very easy to require and achive an IPv4 with > > > > > > dhclient em0 > > > > > > I'm out of ideas ... > > > > > > > > > > > > > > > > > > ==== > > > pciconf: > > > [...] > > > em0@pci0:0:31:6: class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x15d8 > > > subvendor=0x17aa subdevice=0x225a vendor = 'Intel Corporation' > > > device = 'Ethernet Connection (4) I219-V' > > > class = network > > > subclass = ethernet > > > bar [10] = type Memory, range 32, base 0xe8200000, size 131072, enabled > > > cap 01[c8] = powerspec 3 supports D0 D3 current D0 > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > > cap 13[e0] = PCI Advanced Features: FLR TP > > > > > > [...] > > > > > > dmesg: > > > ichsmb0: port 0xefa0-0xefbf mem > > > 0xe8253000-0xe82530ff at device 31.4 on pci0 em0: mem > > > 0xe8200000-0xe821ffff at device 31.6 on pci0 em0: EEPROM V0.1-3 > > > em0: Using 1024 TX descriptors and 1024 RX descriptors > > > em0: Using an MSI interrupt > > > em0: Ethernet address: 48:2a:e3:3a:cf:52 > > > em0: netmap queues/slots: TX 1/1024, RX 1/1024 > > > > > > > > > > > > > > > > > > > > > > > ------=_Part_3614_1576089190.1764323768284 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ok.

Can you copy paste the console output of the booting system up until the login prompt? Or setup /var/log/console.log via /etc/syslog.conf and share that output.

Regards,
Ronald.

 

Van: FreeBSD User <freebsd@walstatt-de.de>
Datum: vrijdag, 28 november 2025 10:50
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: FreeBSD CURRENT <freebsd-current@freebsd.org>
Onderwerp: Re: 15-STABLE: dhclient fails on em0 (Lenovo T580)

On Fri, 28 Nov 2025 10:16:15 +0100 (CET)
Ronald Klop <ronald-lists@klop.ws> wrote:

> It might be a typo in your mail, but it might also be the cause of your issue.
> This config needs to be in /etc/rc.conf, not in /etc/src.conf as you state in your mail.
>
> Regards,
> Ronald.

Sorry, a typo.
 
>
>  
> Van: FreeBSD User <freebsd@walstatt-de.de>
> Datum: vrijdag, 28 november 2025 08:26
> Aan: FreeBSD CURRENT <freebsd-current@freebsd.org>
> Onderwerp: 15-STABLE: dhclient fails on em0 (Lenovo T580)
> >
> > I recently switched from FreeBSD 14-STABLE to 15-STABLE (after branching of
> > 16-CURRENT) on my working laptop, physically a Lenovo T580. Its LAN NIC FreeBSD
> > recognizes as em0 (see below). System is at: 15.0-STABLE #16
> > stable/15-n281349-b903f27e171b: Fri Nov 28 05:20:32 CET 2025 amd64. Kernel config:
> > GENERIC. Configuration has been setup and renewed acording to changes, consider the
> > system as a fresh install.
> >
> > Problem: em0 never gets an IPv4 via DHCP on startup (init process via rc.conf).
> >
> > Configured in /etc/src.conf:
> > [... WORKAROUND ...]
> > netwait_enable="NO"
> > netwait_if="em0"
> > [...]
> >
> > and on a regular basis:
> > [...]
> > ifconfig_em0="DHCP"
> > ifconfig_em0_ipv6="inet6 accept_rtadv -ifdisabled nud -no_radr auto_linklocal"
> > [...]
> >
> > Very strange: after a final boot up, its very easy to require and achive an IPv4 with
> >
> > dhclient em0
> >
> > I'm out of ideas ...
> >
> >
> >
> >
> >
> > ====
> > pciconf:
> > [...]
> > em0@pci0:0:31:6:        class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x15d8
> > subvendor=0x17aa subdevice=0x225a vendor     = 'Intel Corporation'
> >     device     = 'Ethernet Connection (4) I219-V'
> >     class      = network
> >     subclass   = ethernet
> >     bar   [10] = type Memory, range 32, base 0xe8200000, size 131072, enabled
> >     cap 01[c8] = powerspec 3  supports D0 D3  current D0
> >     cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
> >     cap 13[e0] = PCI Advanced Features: FLR TP
> >
> > [...]
> >
> > dmesg:
> > ichsmb0: <Intel Sunrise Point-LP SMBus controller> port 0xefa0-0xefbf mem
> > 0xe8253000-0xe82530ff at device 31.4 on pci0 em0: <Intel(R) I219-V SPT(4)> mem
> > 0xe8200000-0xe821ffff at device 31.6 on pci0 em0: EEPROM V0.1-3
> > em0: Using 1024 TX descriptors and 1024 RX descriptors
> > em0: Using an MSI interrupt
> > em0: Ethernet address: 48:2a:e3:3a:cf:52
> > em0: netmap queues/slots: TX 1/1024, RX 1/1024
> >
> >  
> >
> >
> >   
>
>  
 

  ------=_Part_3614_1576089190.1764323768284-- From nobody Fri Nov 28 10:05:34 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 4dHppM44D2z6JbDg for ; Fri, 28 Nov 2025 10:05:47 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (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 4dHppJ2vKzz3DWV for ; Fri, 28 Nov 2025 10:05:44 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=qydJijKC; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:30 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 9F8BE240940 for ; Fri, 28 Nov 2025 11:05:37 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 09CEA2403AE for ; Fri, 28 Nov 2025 11:05:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764324336; 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=rtV+XCXUPbQGrWKZqfa+0ywqMzr3C00yU/apTHCZBDg=; b=qydJijKCx+ozj8J90Y5hUhZUFlqZV3hFc69Mn3dhRX4CBZwDPpgbmrXq0UInCTqsqFpZQR 2dfdqjFMmt2RoFKXTyL/3gneuG6uv7+my8VJ0FO+PumTIN7kR1nXPYv9Vhfpxtq6JAXa6A bLemPAiUUsgoSi15/nmirX1MNx+NaWWWTX0I/RIvwJDuD8IraGppwSkF+mJNXHmPpUufLF xoLC31wKVIFm7i4M+GobjZjyRrIsoV8A06H18Y6+sLTBSKpNitF4dwAFGUHxO2hBk1ShLt rK8qL5gSrnu7KYD588C06qNPm0DP3FNhOS+SNe97TDn0KVAgiq1IkafiI6FiMQ== Received: from hermann (dynamic-2a02-3100-2d64-3302-1bfd-4657-cf65-5231.310.pool.telefonica.de [IPv6:2a02:3100:2d64:3302:1bfd:4657:cf65:5231]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id CA9F5240357 for ; Fri, 28 Nov 2025 11:05:35 +0100 (CET) Date: Fri, 28 Nov 2025 11:05:34 +0100 From: FreeBSD User To: FreeBSD CURRENT Subject: Re: 15-STABLE: dhclient fails on em0 (Lenovo T580) Message-ID: <20251128110534.3987f908@hermann> In-Reply-To: <20251128082630.3dbea678@hermann> References: <20251128082630.3dbea678@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: cf2643 X-Rspamd-UID: c43c09 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[walstatt-de.de]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4dHppJ2vKzz3DWV On Fri, 28 Nov 2025 08:26:30 +0100 FreeBSD User wrote: > I recently switched from FreeBSD 14-STABLE to 15-STABLE (after branching of 16-CURRENT) > on my working laptop, physically a Lenovo T580. Its LAN NIC FreeBSD recognizes as em0 > (see below). System is at: 15.0-STABLE #16 stable/15-n281349-b903f27e171b: Fri Nov 28 > 05:20:32 CET 2025 amd64. Kernel config: GENERIC. > Configuration has been setup and renewed acording to changes, consider the system as a > fresh install. > > Problem: em0 never gets an IPv4 via DHCP on startup (init process via rc.conf). > > Configured in /etc/src.conf: > [... WORKAROUND ...] > netwait_enable="NO" > netwait_if="em0" > [...] A typo: strike /etc/src.conf, set /etc/rc.conf and netwait_enable="YES" netwait_if="em0" Even those settigs do not have any positive effect. While using rtsol and rtsold for IPv6 - which works at the end and our router provides me with a set of IPv6 addresses, I also watch some strange bootup messages regarding rtsol unable to send because it is forbidden! Since rtsol/rtsold aquires successful an IPv6 and after successful bootup aquiring an IPv4 via "dhclient em0" points me towards IPFW. I use IPFW, scheme "workstation". It seems ipfw is active way to early and blocking by default any traffic and so blocking successful any aquisition of either IPv4 and IPv6. This is quite new on FreeBSD 15 (I used 14-STABLE until 16-CURRENT has branched off). > > and on a regular basis: > [...] > ifconfig_em0="DHCP" > ifconfig_em0_ipv6="inet6 accept_rtadv -ifdisabled nud -no_radr auto_linklocal" > [...] > > Very strange: after a final boot up, its very easy to require and achive an IPv4 with > > dhclient em0 > > I'm out of ideas ... > > > > > > ==== > pciconf: > [...] > em0@pci0:0:31:6: class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x15d8 > subvendor=0x17aa subdevice=0x225a vendor = 'Intel Corporation' > device = 'Ethernet Connection (4) I219-V' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xe8200000, size 131072, enabled > cap 01[c8] = powerspec 3 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 13[e0] = PCI Advanced Features: FLR TP > > [...] > > dmesg: > ichsmb0: port 0xefa0-0xefbf mem > 0xe8253000-0xe82530ff at device 31.4 on pci0 em0: mem > 0xe8200000-0xe821ffff at device 31.6 on pci0 em0: EEPROM V0.1-3 > em0: Using 1024 TX descriptors and 1024 RX descriptors > em0: Using an MSI interrupt > em0: Ethernet address: 48:2a:e3:3a:cf:52 > em0: netmap queues/slots: TX 1/1024, RX 1/1024 > > From nobody Fri Nov 28 11:22: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 4dHrVy6s3fz6Jjgm; Fri, 28 Nov 2025 11:22:34 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4dHrVy0HFpz3SR3; Fri, 28 Nov 2025 11:22:33 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=FIXJ8uOv; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 4CA042405CA; Fri, 28 Nov 2025 12:22:26 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id BAB89240552; Fri, 28 Nov 2025 12:22:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764328944; 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; bh=bqQRIb+ZAPbGkriooJoFO4LRCYxXM2rIuXK0o6bMN9I=; b=FIXJ8uOvE+qV47hyAw/HaLGOETCxPDaxkOFkvWJ0twPCeXzoyEY8R9GV8uvfzDmjXaItIz nqgxlv3gy0vnteNq+ahRbHztUF9qx+tbvkdxRVOviRFL/BxvYTG3Ols1+KfT9Qu4n5kUgX yNV6hcVauWpIdvkh5/BSmkD+8aW09R8/EQpiIEedh0bB0QPRymeLVqOvc5WcuHMIRt1P4g cjHwQA0O5YnhQrZ/h81KHfPPLwGavoi7ejtjmZxIIvXXaeMMMKMpk2/OrtS+oksECOlALy pVNfn6nzYK/O2nsIX/2fMb/1UxQAF9YuwGQizoCcG3OToIbSdf437VpcM8nGrQ== Received: from hermann (dynamic-2a02-3100-2d64-3302-1bfd-4657-cf65-5231.310.pool.telefonica.de [IPv6:2a02:3100:2d64:3302:1bfd:4657:cf65:5231]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 03C7C240182; Fri, 28 Nov 2025 12:22:23 +0100 (CET) Date: Fri, 28 Nov 2025 12:22:23 +0100 From: FreeBSD User To: FreeBSD Ports , FreeBSD CURRENT Subject: pkg-static: dir '/usr/local/lib/compat/pkg' is missing Message-ID: <20251128121823.1b9c9bad@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: e35826 X-Rspamd-UID: ea0c04 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]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ports@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4dHrVy0HFpz3SR3 Rebuild of pkg stops with the error shown below. The required input hinders unattended or almost unattended rebuild via portmaster in my case. How can this issue be resolved? '/usr/local/lib/compat/pkg' is missing on both recent 16-CURRENT and 15-STABLE. Do I miss something here? Kind regards oh [...] ===>>> Creating a backup package for old version pkg-2.4.2_1 Creating package for pkg-2.4.2_1 pkg-static: dir '/usr/local/lib/compat/pkg' is missing pkg-static: package creation failed ===>>> Package creation failed for pkg-2.4.2_1! ===>>> Ignore this error [i] ===>>> Abort update [a] ===>>> Retry [r] ===>>> How would you like to proceed? [i] From nobody Fri Nov 28 11:34: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 4dHrmv0VGpz6Jkj8 for ; Fri, 28 Nov 2025 11:34:39 +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 4dHrmt700Cz3Vtw; Fri, 28 Nov 2025 11:34:38 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764329679; 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=zaBr95/eHlxCUfhCILeoNR62h6jqQciXKAutla2mbVY=; b=VC2lL/6qro6JxnXBIOlIqSCNeRNxsjGJQ1lwzN4YLiulH+iTySaPdLq/mnDDJfpLyLVwY2 PcV3K6okmcg/Bt2G9Qz+saGXzmg0EbEWT4nelM2sm27Bt2cwzODzm4Y7nGMHFvRfAHXTue Cmpf8CTEWbVB+3krr94NkT5czMdh8ldlkbJP6l4r8+OVEitPrGVzwxzpCw43i7g7nHH/FQ ajGwZh6JD1Bu0wYYuWvpheWQuf1jHXq9MDTyvRtV6sGurdC5AmnU9LpR9PGV/5O11Mdqx/ LYjaWHQPZH9pMiKcKXJAB0f8PLtICbyRCZY78Bcl5wqkAHgMkLtuQNSRNj8R+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764329679; 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=zaBr95/eHlxCUfhCILeoNR62h6jqQciXKAutla2mbVY=; b=OzEUAPxcPJ8NREkSIHm5IGYdyWpmU+leZ5+dqkhRR76cJKtaqcRjS/pHlrLmEGA0+ds4Gn bL0bWowJ01wCZOqqAWuSF7KtgpJlPVwhfa0ciUH2ZdF4OgXI136NVhyHIz3mlcx1cBbyV/ +DWPzbB7vj+FNt1x6iI1SCz3HTj1IciKsxouGZ6kHQ57+pYQZ7pk+ABfvLrW3Cf+D/GeYK 2G+38cE6Mg9+83NJkIAoS2dGdqcjtz4acBokp0slmr0qciCvSuH8qXYJpIkI3BVrjvK662 q1na5FqqtSIF3LvYaGpFE9lGB4Yv0wRU28IPosz2n36n24ABnqjbcNosFHUYbg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764329679; a=rsa-sha256; cv=none; b=QIs+oCK44bm+WwM/NkSOnzVx6ZFYg0W+pxeMCiWV+JWbHTwJhVc3UTrfgNJlYw3OsI02wM BSEvze4gJmL6ryZZbB0JbvM/mmrLNZCMVxhHTZ3jbXq5Os659UV0ZZNsgzMRdnAzghr5SR allEMXdv+en/pBIGofUGLa9Go5Y2OWnz8awfCJd4p0jfE5IXynD0NCOiDTpUnLV6DJylOu 4qJYuu9TWNUioRDBg8FqnqCYZMUABi4Ysksv8cweR6PVJPI0H09N8bvNbXI/E2Qmq+gXb4 4McXkh+nC88qzeyh8sdGS43sRb7qD6FvlmFBOE8g7SrGXfvV3eaG6LmtIrvU3w== 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 4dHrmt5Zh8zwtL; Fri, 28 Nov 2025 11:34:38 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 7FA328DEBB; Fri, 28 Nov 2025 12:34:37 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: FreeBSD User Cc: FreeBSD CURRENT Subject: Re: 15-STABLE: dhclient fails on em0 (Lenovo T580) In-Reply-To: <20251128110534.3987f908@hermann> (FreeBSD User's message of "Fri, 28 Nov 2025 11:05:34 +0100") References: <20251128082630.3dbea678@hermann> <20251128110534.3987f908@hermann> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 28 Nov 2025 12:34:37 +0100 Message-ID: <86fr9yie5u.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 FreeBSD User writes: > I use IPFW, scheme "workstation". It seems ipfw is active way to early an= d blocking > by default any traffic and so blocking successful any aquisition of eithe= r IPv4 and IPv6. As a workaround, add this to /boot/loader.conf: net.inet.ip.fw.default_to_accept=3D"1" DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Fri Nov 28 11:36:46 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 4dHrqn71qwz6Jkd7; Fri, 28 Nov 2025 11:37:09 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (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 4dHrqm4jBbz3Whn; Fri, 28 Nov 2025 11:37:08 +0000 (UTC) (envelope-from herbert@gojira.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=MBO0001 header.b=vcwq7Ewf; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 80.241.56.172 as permitted sender) smtp.mailfrom=herbert@gojira.at Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (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-202.mailbox.org (Postfix) with ESMTPS id 4dHrqh3MYHz9tYh; Fri, 28 Nov 2025 12:37:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gojira.at; s=MBO0001; t=1764329824; 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=mxzQJXAM3VmUXd1D0SEZLT6PVeGyvfesbPpbYTRkrio=; b=vcwq7Ewfue0cEhfDqvygni/y6JKXkJs/Icyl6C2vmQHiwsWtu77VIS8/heqiK7NijFPQQq 9WbP1HUStCJgu6ouo45RjpUCFi+IAskrkY1jEMDKRpvYRgWG8wXM0sGp58n2Ow9fF1/0V9 4DY2I+kLYJtVu/uMXaII2xt122cs+mHglCqeAg2gAfUBQVKlNFbRvIbPZVRIOMAj/eG0S5 xGZodFUrDC83WkA2iZ3MHQeGGwUiQjv99I2V7NncclGMRfdnV5+WJn2RCaK21CRLY1c2An SS63VIS6Wmtt9oYQQZIzhLdsT14+gqO90IwMVbqfDMIdsWEjYi6p5etYz7CpcQ== Date: Fri, 28 Nov 2025 12:36:46 +0100 Message-ID: <87sedymlrl.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: ports@freebsd.org, current@freebsd.org Subject: Re: pkg-static: dir '/usr/local/lib/compat/pkg' is missing In-Reply-To: <20251128121823.1b9c9bad@hermann> References: <20251128121823.1b9c9bad@hermann> 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]; RCVD_IN_DNSWL_LOW(-0.20)[80.241.56.172:from,2001:67c:2050:b231:465::102:received]; R_DKIM_ALLOW(-0.20)[gojira.at:s=MBO0001]; R_SPF_ALLOW(-0.20)[+ip4:80.241.56.0/21]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current@freebsd.org,ports@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: 4dHrqm4jBbz3Whn On Fri, 28 Nov 2025 12:22:23 +0100, FreeBSD User wrote: > > Rebuild of pkg stops with the error shown below. The required input hinders > unattended or almost unattended rebuild via portmaster in my case. > > How can this issue be resolved? '/usr/local/lib/compat/pkg' is missing on both recent > 16-CURRENT and 15-STABLE. Do I miss something here? > > Kind regards > > oh > > [...] > ===>>> Creating a backup package for old version pkg-2.4.2_1 > Creating package for pkg-2.4.2_1 > pkg-static: dir '/usr/local/lib/compat/pkg' is missing > pkg-static: package creation failed > > ===>>> Package creation failed for pkg-2.4.2_1! > > ===>>> Ignore this error [i] > ===>>> Abort update [a] > ===>>> Retry [r] > > ===>>> How would you like to proceed? [i] Portmaster is removing empty /usr/local/lib/compat/pkg: 3913 [ -z "$temp" ] && temp=`find $LOCALBASE_COMPAT -type d -empty 2>/dev/null` 3914 if pm_isdir "$temp"; then 3915 pm_sv Deleting the empty $LOCALBASE_COMPAT 3916 pm_rmdir_s $temp 3917 fi 3918 unset temp https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290829 From nobody Fri Nov 28 14:38:55 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 4dHwsp375tz6HbC1; Fri, 28 Nov 2025 14:39:10 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (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 4dHwsn6jxnz3vrS; Fri, 28 Nov 2025 14:39:09 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 8A9F4240524; Fri, 28 Nov 2025 15:38:58 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id B9C192403E3; Fri, 28 Nov 2025 15:38:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764340736; 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=lsv2Nx//1NCqJrwgHkNl/rgkW7jqz3q1lOwTfSgPbvg=; b=DQoNOnfA62hPsQrYFXtJiu1Pnr4MM0/sOnrFVhXtQCtcIV2tToMekkaO3n7BfVrotxC2qR tzYPIsz7brmFzndjJFrAMIoW90kq6K3Lcpuuv8pMlA+2ksowl2rt+ve2qoLbIXRy9Ms2qk sBMSAeY7sW1NvskU7amlc08P2yJG5npoOR3dDca3HA4AQiJtPVVPU2uUjYdfjnDZuKDsqk 76dBExG5W6o5EsMJyKCbYgZ+hrEe/GPxkxVgSuOev3c940xsfYLL1QSNqfACS+l8JFloLE qNoK2QzvtZjKcX41Ph820nqwiJCRk3fXLLtCLOL5f0j8nmGNsZIBwxSXX0rHHA== Received: from hermann (dynamic-2a02-3100-2d64-3302-1bfd-4657-cf65-5231.310.pool.telefonica.de [IPv6:2a02:3100:2d64:3302:1bfd:4657:cf65:5231]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 837A42402EB; Fri, 28 Nov 2025 15:38:56 +0100 (CET) Date: Fri, 28 Nov 2025 15:38:55 +0100 From: FreeBSD User To: "Herbert J. Skuhra" Cc: ports@freebsd.org, current@freebsd.org Subject: Re: pkg-static: dir '/usr/local/lib/compat/pkg' is missing Message-ID: <20251128153716.5a2bc73f@hermann> In-Reply-To: <87sedymlrl.wl-herbert@gojira.at> References: <20251128121823.1b9c9bad@hermann> <87sedymlrl.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-Transfer-Encoding: 7bit X-Rspamd-UID: 850803 X-Rspamd-UID: 016d55 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: 4dHwsn6jxnz3vrS On Fri, 28 Nov 2025 12:36:46 +0100 "Herbert J. Skuhra" wrote: > On Fri, 28 Nov 2025 12:22:23 +0100, FreeBSD User wrote: > > > > Rebuild of pkg stops with the error shown below. The required input hinders > > unattended or almost unattended rebuild via portmaster in my case. > > > > How can this issue be resolved? '/usr/local/lib/compat/pkg' is missing on both recent > > 16-CURRENT and 15-STABLE. Do I miss something here? > > > > Kind regards > > > > oh > > > > [...] > > ===>>> Creating a backup package for old version pkg-2.4.2_1 > > Creating package for pkg-2.4.2_1 > > pkg-static: dir '/usr/local/lib/compat/pkg' is missing > > pkg-static: package creation failed > > > > ===>>> Package creation failed for pkg-2.4.2_1! > > > > ===>>> Ignore this error [i] > > ===>>> Abort update [a] > > ===>>> Retry [r] > > > > ===>>> How would you like to proceed? [i] > > Portmaster is removing empty /usr/local/lib/compat/pkg: > > 3913 [ -z "$temp" ] && temp=`find $LOCALBASE_COMPAT -type d -empty 2>/dev/null` > 3914 if pm_isdir "$temp"; then > 3915 pm_sv Deleting the empty $LOCALBASE_COMPAT > 3916 pm_rmdir_s $temp > 3917 fi > 3918 unset temp > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290829 > > ups, I see, problem already known. Thank you! Kind regards oh From nobody Fri Nov 28 14:55:03 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 4dHxGR2L4Cz6HcsS; Fri, 28 Nov 2025 14:57:03 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor.nl2k.ab.ca (doctor.nl2k.ab.ca [204.209.81.1]) by mx1.freebsd.org (Postfix) with SMTP id 4dHxGQ2JBkz41lM; Fri, 28 Nov 2025 14:57:02 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Authentication-Results: mx1.freebsd.org; none Received: from doctor by doctor.nl2k.ab.ca with local (Exim 4.98.2 (FreeBSD)) (envelope-from ) id 1vOzsF-00000000GSq-48nW; Fri, 28 Nov 2025 07:55:03 -0700 Date: Fri, 28 Nov 2025 07:55:03 -0700 From: The Doctor To: FreeBSD User Cc: FreeBSD Ports , FreeBSD CURRENT Subject: Re: pkg-static: dir '/usr/local/lib/compat/pkg' is missing Message-ID: References: <20251128121823.1b9c9bad@hermann> 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: <20251128121823.1b9c9bad@hermann> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6171, ipnet:204.209.81.0/24, country:CA] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dHxGQ2JBkz41lM On Fri, Nov 28, 2025 at 12:22:23PM +0100, FreeBSD User wrote: > Rebuild of pkg stops with the error shown below. The required input hinders > unattended or almost unattended rebuild via portmaster in my case. > > How can this issue be resolved? '/usr/local/lib/compat/pkg' is missing on both recent > 16-CURRENT and 15-STABLE. Do I miss something here? > > Kind regards > > oh > > [...] > ===>>> Creating a backup package for old version pkg-2.4.2_1 > Creating package for pkg-2.4.2_1 > pkg-static: dir '/usr/local/lib/compat/pkg' is missing > pkg-static: package creation failed > > ===>>> Package creation failed for pkg-2.4.2_1! > > ===>>> Ignore this error [i] > ===>>> Abort update [a] > ===>>> Retry [r] > > ===>>> How would you like to proceed? [i] > Note to the porter, you might be missing libjitterentropy. -- Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism ; All I want to hear from JEsus Christ is WEll done Good and Faithful servant From nobody Fri Nov 28 16:51:32 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 4dHzlK2C3Fz6HqCs for ; Fri, 28 Nov 2025 16:48:45 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (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 4dHzlK00Frz4LFc for ; Fri, 28 Nov 2025 16:48:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-8b220ddc189so211011085a.0 for ; Fri, 28 Nov 2025 08:48:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764348524; x=1764953324; 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=xSGZInKqwOxzbVKymWmQDqL+YWEickbdcl06tVH+Umo=; b=HtZN7zvRjN3JpPMfCGx01oUMKmCSDVw+/fCbog2l640AEee0leuVcyjU4yUPieR5EK aiWh5KY+K16qBhaWu1ZdZdQM3IZJOXLR69wdCxmpyIMfwQC1R47BQK19ckiqu8YAS8Dq V/PWw5rPcQdQrMGngLhPZrM0nWBmfcI4HixG5CEU0knLtq3DalPpvmJio7/j0tUQUMKs auaEuMQIUwCvsWsH3/ke7CCB2zGT4NfHfMR0mGUUyKGWPCOYBgEI51IopTIJmISlPK/2 dqVC5wEhaywBBEQnF44/6mYHeRoigfRyA9Mfm47Zkgy980Vng1bWc0BYXK7MnZzs3fRm 7grw== X-Forwarded-Encrypted: i=1; AJvYcCUOs009sTpOTTrgq0GU00zn+pAE6pJfCTmsIN3cr1Oj3UxJnbRrF6tWGrfhJi7Jmpd5zu4ygIehCkBuyT1cYiU=@freebsd.org X-Gm-Message-State: AOJu0Yw8bla8uhckafpWKE8wasBMcOoTbs/zMQ7R52B9tCGGoOnefCQL i9/MeyFQgnXe4+KTNYfek/3FwLFWxdJ/6jmmpRIAIqKDtHvkQH9gJa136ih1gnd8FzGdp0JHdoO Hynp9l5XOyaalmQQc2N6q3YpAQMAyY6jnAnre X-Gm-Gg: ASbGncuw723iF5SRb3SG3I3SDdgn4/j6jkuQIRcPO2+b8iRz1U4nH4UyRkmdzYuHSvJ G01BBQGFzxi2QdGWkoeEvKSXE0V6WS4zZrh8WtW5HlX5zkmOhzdLF+LeM7SMNLLfNPtpxooPpGI 7J8tEDikZwazGEwPJ+RuLLftdIGPGi4IWSTK58EfeMk8rQxkGuld7vc7ogjzjkWsRJ5p1MM7MID ANJLVz3Vr6sGvHUlJvVAp5q4esiJx8fdFR3GiwgG7A95av/GFWDrsk61nNtfGMJdz76z0ay+zge eHe4VbM+XDZSi1ly+2e1p8OHTxsTcg== X-Google-Smtp-Source: AGHT+IE0Qk/Z1YLslDi8kXbi8RxJYjwJADHh8v7ja93a1imPQoss2uAIrm4HMDJBq+tVDnI4TfICMFosGhHxtSpU77E= X-Received: by 2002:a05:620a:414b:b0:815:630d:2cbd with SMTP id af79cd13be357-8b33d1fd830mr3856489685a.34.1764348524208; Fri, 28 Nov 2025 08:48:44 -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: Adrian Chadd Date: Fri, 28 Nov 2025 08:51:32 -0800 X-Gm-Features: AWmQ_bnMO2eofoSm9hvTXdqykZ2HbvuWytqNRHT2e1Qv3meJQcXKw5aH6Q-iQB4 Message-ID: Subject: Re: looking for testers for if_rge - RTL8125/8126/8127 ethernet driver To: Florian Smeets Cc: FreeBSD Net , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dHzlK00Frz4LFc On Thu, 27 Nov 2025 at 10:13, Florian Smeets wrote: > > On 23.11.25 03:16, Adrian Chadd wrote: > > hi! > > > > i've ported Kevin Lo's openbsd driver for these realtek chipsets to FreeBSD. > > It works well enough for me to use on my laptop w/ RTL8125B / Killer E3000. > > I'm now opening it up to others who are willing to build/run a kernel > > module to test the driver out and report back. > > > This is great. Finally, an in tree driver for these very common NICs. > The 1100.00 version of the net/realtek-re-kmod was just unreliable for > me (constant hangs, no matter which options I turned off and on). I've > only done light testing with the official 1101.00 driver. I was able to > wedge it with less than a minute of iperf3, and the ifconfig down/up > dance that was able to revive the interface with 1100.00 was not able to > recover the interface. > > I ran if_rge on my NAS and did some testing. I haven't had one hang with > this driver, even after pounding the network for hours. That's a big > plus for me. Thanks. > > I was able to achieve close to 2.5Gb/s TX and close to 1Gb/s RX with > iperf3 --bidir. > > CPU usage appears to be substantially higher than with the official > Realtek driver. That's a good data point. > > [intr{irq59: rge0}] goes to around 50% of one core, and [kernel{rge0 > taskq thread}] hovers between 20-25% when running the above iperf3 tests. > > With the official 1101.00 driver, the only process using > 1% CPU is > this one [kernel{re0 taskq}] and it is around 10% with the test > mentioned above. I'll go dig into that a bit. It shouldn't be taking very much CPU to process this number of packets; the bulk of the CPU should be used by the IP stack. I'll go run some profiling over the next few days and see if I can nail down what I'm doing poorly. Hopefully it's something stupid on my end. ;-) -adrian From nobody Fri Nov 28 16:57: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 4dHzsx59jhz6Hqqx for ; Fri, 28 Nov 2025 16:54:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (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 4dHzsx2YZxz4NCp for ; Fri, 28 Nov 2025 16:54:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-8b22b1d3e7fso186170685a.3 for ; Fri, 28 Nov 2025 08:54:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764348869; x=1764953669; 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=DAJzCcrf493KoRQIx9K9ey9TCq/CtXSNcsZKW6SFX1Q=; b=r1XQHRpcTwPU/xCHFwGx1X+hRK/f9xDoIJSlJTZSjm2uuXx9fqlNEN0TEHSxk7Wdgz HpRp0lnN562RYCxtLj7LxNyQtamfFJAMDDy0b0k3z8GlfgchGnPecygajDAMWqZN2kFU cRFvQTQoJvLnrVe/LVpnlNKrtAMcxXnUuUAF8qQqwn4GFZ2gtYXsi8YrG1x1jFeJ/Sdt JwpbYi2yRQoBS/YIwbppBXC8VWWb+jpn5hHyaWnSEPMCAGuGKCM8UPpBOb/ySWeTF8Pr e1cySBQcLdLj0cnP/oEzUwDm3NFpYvtC99lcf7UgM3ZR6s9TkbAchPAEX2Mc4JHm8M9O eYow== X-Gm-Message-State: AOJu0Yw6lg1P1a0aC4KBZTz2KX85KZ/tsaJ315GkJwuhuhM5QOx5lbpW f9XI7YJthk2fBeToPJaWGoCLSiMvuvIh8Otr/q+f1X+d9gMF/p4KjBs4ySX6uFLZVYiCnoUx+fP u45LQMcfQ1pNZBZa3l3JPNT6LGkDOSqg= X-Gm-Gg: ASbGnctesKEE21KVySG6eagVTGf3qEnPO7i9gCgZNHGOJ2nNfAG6o9gttGkdNZbevUr 84c7yP9/ymVj/26HPrxoICv6adY+60j9HHOOQ3yBU44m4MA5phF0gmpCB4s3goOnCWYOts6v+WA 4m3sEP+mjyQvmwfUb6VnNW8B+ix8nIUtZA4Be12eVbDlnOonStHQhPvb6sJW6HtEZ7vobzyz9WB LxgFOXe9opVVLp00kg4+jZSEzsGk81yw8USCST/FnUkIdyphESAdn6vFr6Vf0tLn5Rw6yOep14A 1T+VIvTnDxhgF+wBi0yLTdgxnfvT5A== X-Google-Smtp-Source: AGHT+IHAkIvkRiYwhg/Arw8nQvgLEL05BX1dTVovCs0CYvbfc5JP6qr75rQ6AZBRuFFdCcbO84yNCQfgYCrldVu8ado= X-Received: by 2002:a05:620a:45aa:b0:8b1:adfd:f850 with SMTP id af79cd13be357-8b33d23a77cmr3822261685a.18.1764348868756; Fri, 28 Nov 2025 08:54:28 -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: <20251126163059.3376d3e8@hermann> <77c2a2fb-ac5f-4b4a-98c6-660a39ee87b2@gmail.com> <950fe459-217b-4066-99d8-1fa3247d0d84@gmail.com> In-Reply-To: <950fe459-217b-4066-99d8-1fa3247d0d84@gmail.com> From: Adrian Chadd Date: Fri, 28 Nov 2025 08:57:17 -0800 X-Gm-Features: AWmQ_bmAVu5ZD8RLNHwZFTVZIh4qWCMsUXAvWtxNmAD4aXMScfQLityy0wBckoI Message-ID: Subject: Re: FreeBSD/X11: Howto revive DisplayPort? To: Paul Floyd Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" 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: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: 4dHzsx2YZxz4NCp [snip] Chances are it's because we're just not doing any of the required EDID style chattery until the drm framework is loaded. The EFI framebuffer device in vt doesn't do any of this. Whatever is negotiated when the machine firmware boots is what you're stuck with. -adrian From nobody Sat Nov 29 08:59:04 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 4dJPH23nfKz6JqPt for ; Sat, 29 Nov 2025 08:59:10 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (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 4dJPH13MKLz3vKr for ; Sat, 29 Nov 2025 08:59:09 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=VlJ93hO2; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 89FF8240440; Sat, 29 Nov 2025 09:59:07 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id CAF0024003C; Sat, 29 Nov 2025 09:59:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764406745; 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=uALXwXcBwacrIoej8aNktcpr7ptsGHvhyNsVi38+/r4=; b=VlJ93hO2LVczU7QYumk0QNPLz4bqYiwuXsCwqYxCizKwWFbyUdxK3H/W3zu/0kGGkIthOI rpgwSeRYHhYQaFksYrzP94LRh2zpDn5t1LgAr30QI3mZM9T/AmLXizHFpmjrRWCeyss1SY VOmbaCLxf9oKCYvNePgdPOQlhQm5sQnYuOnjfs1DXbb4kQZf/dPIMz0QEwR7HPTR5yrh0p JNrCVuFH/3hFREPFOltwpCu0NMqVxEJjKMEZff9IvEllJO0mUnmBIAeOZVUBJhMdnifKsL wS88p/AcLyag+eMPK+rngRvOgFg2WYdfSbhIOY7rMaThMagzzYip6lwyWO19Ug== Received: from hermann (dynamic-2a02-3100-23f0-d502-fef0-00c8-2d71-c39d.310.pool.telefonica.de [IPv6:2a02:3100:23f0:d502:fef0:c8:2d71:c39d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 8B5CB24002F; Sat, 29 Nov 2025 09:59:05 +0100 (CET) Date: Sat, 29 Nov 2025 09:59:04 +0100 From: FreeBSD User To: Warner Losh Cc: FreeBSD CURRENT Subject: Re: freezing on unmountin ext2fs USB device Message-ID: <20251129095452.5905b7d5@hermann> In-Reply-To: References: <20251123151439.361dd84c@thor.sb211.local> <20251128062140.120e8369@hermann> 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/mixed; boundary="MP_/g7AqgxE.jh0RojGUA2zdZjg" X-Rspamd-UID: 75b4f1 X-Rspamd-UID: 596ade X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:+]; DMARC_NA(0.00)[walstatt-de.de]; 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-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4dJPH13MKLz3vKr --MP_/g7AqgxE.jh0RojGUA2zdZjg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 27 Nov 2025 23:33:50 -0700 Warner Losh wrote: > On Thu, Nov 27, 2025, 10:22=E2=80=AFPM FreeBSD User wrote: >=20 > > On Tue, 25 Nov 2025 21:03:01 -0700 > > Warner Losh wrote: > > =20 > > > On Sun, Nov 23, 2025 at 7:15=E2=80=AFAM A FreeBSD User > > > wrote: > > > =20 > > > > Hello, > > > > > > > > running FreeBSD 16.0-CURRENT #4 master-n282101-c8cf5a99f82b: Sun No= v 23 > > > > 13:56:23 CET > > > > 2025 amd64 I'm running into a serious problem when mounting an ext2= fs > > > > formated USB Flash > > > > device (512GB). The devince contains files written by a Linux syste= m, > > > > mounting the USB Flash > > > > via extended4fs, the size of the written datafiles is > 128GB. Dele= ting > > > > those files larger > > > > than some 20GB results in an I/O error reported by FReeBSD (# sudo = rm > > > > /mnt/USB/filename). > > > > Unmounting the ext2fs after deletion (sudo umount /mnt) results in = a =20 > > total =20 > > > > freeze of the box. > > > > No crash, no core dump, nothing. I waited almost an hour hoping for > > > > recover. I have to > > > > physically switch off the box. > > > > > > > > I checked with other USB flash I have at hand, one Samsung 256 GB, = ZFS =20 > > - =20 > > > > no problem, another > > > > 128GB, UFS, no problem and several much smaller (4 - 64GB) with FAT= or =20 > > UFS =20 > > > > filesystems, all no > > > > problem. > > > > > > > > I can not figure out whether it is the USB flash drive itself, the = =20 > > size or =20 > > > > the ext2fs itself > > > > causing the problem. > > > > > > > > Does anybody see similar problems or do have an tip to investigate = =20 > > without =20 > > > > risking my box' > > > > health switching it on/off on failure? > > > > =20 > > > > > > I've not seen this on the smaller tests I've been able to run. > > > > > > So can you share the error messages that you get when you say you get= I/O > > > errors? I'd like to see if this is due to an error in ext2fs or on th= e =20 > > USB =20 > > > drive. It's kinda sounding a little like the particular USB is trigge= ring > > > some kind of issue that at the very least we should work around. Give= n =20 > > that =20 > > > it's not happening on all ext2fs drives you try to access, I'm leaning > > > towards the drive, but you never know. > > > > > > Thanks =20 > > > > Plugging the USB flash gives the following hardware information on the > > console: > > > > [...] > > ugen1.5: at usbus1 > > umass0 on uhub6 > > umass0: on usbus1 > > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00= 10 > > 00 00 > > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > > command > > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > da4: Removable Direct Access SPC-4 SCSI device > > da4: Serial Number somer serial numbers > > da4: 400.000MB/s transfers > > da4: 475000MB (972800000 512 byte sectors) > > da4: quirks=3D0x2 > > [...] > > > > Trying to mount via: # mount -t ext2fs /dev/da4p1 /mnt/image > > > > [...] > > (da4:umass-sim0:0:0:0): got CAM status 0x444 > > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > da4: s/n some serial numbers detached > > (da4:umass-sim0:0:0:0): Periph destroyed > > > > mount: /dev/da4p1: Device not configured > > =20 >=20 > This has the classic hallmarks of a drive that loses its mind on > SYNCHRONIZE CACHE. Normally, we detect that automatically, but sometimes = we > don't. Let's see if this drive is suffering from that. These instructions > are a bit long, but the shorter ones are harder to explain :). >=20 > First, you'll need to find what this drive is. You'll need to use > "usbconfig -v" to find the drive. Redirect that to a file, then search, y= ou > should find something akin to >=20 > ugen0.13: Technology Corp.)> at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5.0Gbps) pwr= =3DON > (76mA) > ugen0.13.0: umass1: >=20 > The first line might not match, and the numbers will be different. But > you'll need the vendor and product IDs from this drive. They are a few > lines later and look akin to the following: > ... > idVendor =3D 0x090c > idProduct =3D 0x1000 > ... You'll find the required output as attachment, desinated usb_asolid.txt. The required identifications should be idVendor =3D 0x24a9 idProduct =3D 0x205a bcdDevice =3D 0x0110 >=20 > Now, remove the drive and type in the following (with your vendor and > product replacing mine): >=20 > usbconfig add_dev_quirk_vplh 0x090c 0x1000 0x0000 > 0xffff UQ_MSC_NO_SYNC_CACHE In my case in question it would be usbconfig add_dev_quirk_vplh 0x24a9 0x205a 0x0000 0xffff UQ_MSC_NO_SYNC_CAC= HE right? >=20 > This will add a quirk to the usb quirk table. You should see NO_SYNC_CACHE > show up in the da4 probe quirk report when you plug the drive back in. >=20 > If that fixes it, please let me know. "Hang on close" or "Periph goes away > on close" very often is due to this. umount will close the device. I may > have additional questions for you to help me add a quirk or a heuristic to > the code... I'm not yet sure, though, of the correlation to big files. It > may be something else, or it may be this. Do not see required state change in output: [...] ugen1.5: at usbus1 umass0 on uhub6 umass0: on usbus1 (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 = 00 00=20 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid co= mmand operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: Removable Direct Access SPC-4 SCSI device da4: Serial Number 25010993010046 da4: 400.000MB/s transfers da4: 475000MB (972800000 512 byte sectors) da4: quirks=3D0x2 ugen1.5: at usbus1 (disconnected) umass0: at uhub6, port 1, addr 4 (disconnected) da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: s/n 25010993010046 detached (da4:umass-sim0:0:0:0): Periph destroyed umass0: detached ugen1.5: at usbus1 umass0 on uhub6 umass0: on usbus1 (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 = 00 00=20 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid co= mmand operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: Removable Direct Access SPC-4 SCSI device da4: Serial Number 25010993010046 da4: 400.000MB/s transfers da4: 475000MB (972800000 512 byte sectors) da4: quirks=3D0x2Tryping to mount=20 [...] Trying to mount /dev/da4p1 (which is the supposed ext4fs/ext2fs partition o= n the USB flash device) results in: WARNING: R/W mount denied. Filesystem is not clean - run fsck and when trying to solve the problem via [...] # /compat/linux/sbin/fsck.ext4 /dev/da4p1 e2fsck 1.46.5 (30-Dec-2021) /compat/linux/sbin/fsck.ext4: No such file or directory while trying to ope= n /dev/da4p1 Possibly non-existent device? and on console (da4:umass-sim0:0:0:0): got CAM status 0x444 (da4:umass-sim0:0:0:0): fatal error, failed to attach to device da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: s/n 25010993010046 detached (da4:umass-sim0:0:0:0): Periph destroyed I think this special "low cost" device did not only lost its mind, it lost = its head also. Regards, Oliver p.s. One note:=20 # gpart show -l da4 =3D> 40 972799920 da4 GPT (464G) 40 972799920 1 (null) (464G) The device in question does have a GPT partition layout. I guess it doesn't= matter here, but I'll add it anyway for the record. >=20 > Warner >=20 > [...] > > > > [...] > > # /compat/linux/sbin/fsck.ext4 /dev/da4p1 > > e2fsck 1.46.5 (30-Dec-2021) > > SINA was not cleanly unmounted, check forced. > > Pass 1: Checking inodes, blocks, and sizes > > Pass 2: Checking directory structure > > Pass 3: Checking directory connectivity > > Pass 4: Checking reference counts > > Pass 5: Checking group summary information > > Error writing file system info: Invalid argument > > > > XXXX: ***** FILE SYSTEM WAS MODIFIED ***** > > > > [...] > > > > detaching and attaching to another USB slot on the same (external) HUB: > > > > [...] > > ugen1.5: at usbus1 > > umass0 on uhub6 > > umass0: on usbus1 > > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00= 10 > > 00 00 > > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > > command > > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > da4: Removable Direct Access SPC-4 SCSI device > > da4: Serial Number some serial numbers > > da4: 400.000MB/s transfers > > da4: 475000MB (972800000 512 byte sectors) > > da4: quirks=3D0x2 > > linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback fd=3D3, cmd=3D0= x127c > > ('\^R',124) is > > not implemented linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback > > fd=3D3, cmd=3D0x125e > > ('\^R',94) is not implemented (da4:umass-sim0:0:0:0): got CAM status 0x= 444 > > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > da4: s/n some serial numbers detached > > (da4:umass-sim0:0:0:0): Periph destroyed > > > > [...] > > > > I can not even mount the device on CURRENT (FreeBSD 16.0-CURRENT #1 > > master-n282217-34d66b0c96d5: Fri Nov 28 05:15:56 CET 2025 amd64). > > > > Package used for linux operation: emulators/linux-rl9 > > =20 --MP_/g7AqgxE.jh0RojGUA2zdZjg Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=usb_asolid.txt ugen1.5: at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (76mA) ugen1.5.0: umass0: bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0320 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0009 idVendor = 0x24a9 idProduct = 0x205a bcdDevice = 0x0110 iManufacturer = 0x0002 iProduct = 0x0003 iSerialNumber = 0x0004 bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x002c bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x0080 bMaxPower = 0x0026 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x0008 bInterfaceSubClass = 0x0006 bInterfaceProtocol = 0x0050 iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0400 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x06, 0x30, 0x03, 0x00, 0x00, 0x00 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0400 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x06, 0x30, 0x03, 0x00, 0x00, 0x00 --MP_/g7AqgxE.jh0RojGUA2zdZjg-- From nobody Sat Nov 29 10:29:46 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 4dJRHt11l0z6HXCd for ; Sat, 29 Nov 2025 10:30:02 +0000 (UTC) (envelope-from otis@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 4dJRHt0MQsz44Ls; Sat, 29 Nov 2025 10:30:02 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764412202; 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=dvtbb9CdAmOVRSZFbjDC04ZyENp4RRBCjvXQPnkzzMU=; b=QPfCxVUBZ5WhqR3RDzxAeaOsdOaY+2Mpsi3xQdjS6CD1QKM9+1izTXe0ZwK+rH+FQR6eSV BekUmbMYYGbcHk2P8aQRj+HzKQ1zt+huPW5fu2GYvv6u9CXO2Dq9IdH70uNrk8A7ig4sEa XFj4ZHTFRfnbIDGwoDC4tlVWi3VicJk3D0pIAYuvWe4BtL2Dmor2Udjl2IRCkqQ99uhfYK bXezRSwxh/x0xJ03MElSmrN7cbYBzNuGrePGDdhhihFxo9plYdM/tugKg3iacbG79dk/lK ZQCRJufntGyWESb+vYrGqb8sFalXyVzVdv5v72pD53UVS6+U73OWtOjRCZe9KA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764412202; 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=dvtbb9CdAmOVRSZFbjDC04ZyENp4RRBCjvXQPnkzzMU=; b=erdQEMSuPFYajrt+VuOomjLif8m5FbfTwNjS90kIQTYFI9V8CAqK2OUjd9uKhSzaeR9WpB 8DjI7Grfpth6SJznX0TH4SQHqTPXGo2VZ/V0H56RsnkhEdE3KrdrB5zXPgZm/vp8Nk3ELZ +Q+x/7KEf+GnZFKWOz9UcGY6TEVyW0oCDKefwLqZ6OZ2O7q/QHtQ/V0ODj+U6Z4p6ccNu2 LxleItoUQoizkiHZvfMSmDi4mWbOqqboBg/vPepCOFmq8t9ATGRv1rbQVYuo+z3NTxLTWL wrH2COmTvy6GefEFhLtG3b0t5FluISJverbx+ZXD+80b0OWhO3MmdvG46nnK3g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764412202; a=rsa-sha256; cv=none; b=bKMiAu+D6vSF9QlPwdmb0r3rg1RIBd4gRN3yFZb6boPFGel9O/idBDs3L4VtRTQTwEnxr8 GFOLoVPw2s9faBu2MlKOxUdC01x0j1OzAT4PH5S8kch9HWK1mMSp0s/7EowIHGoeSq5g+N yTCehAYCYfN4DYPhQXXRFF0EelE7N0E2QwqviEGnSK6m+L9/WgyRXJtLuB9qCGFfE51ba9 It9SsjexEc9tvHe/B1W0rBTINkXEc3CQVbpn4OcgVROc0OjI76kL/9QeKC3NUhtvDY2Uph UmSPG5RNlQ8ODkIHm64EgjnNCaxfuwnBKKsry+TcSsO4AniygaI2q0OZJrVw2Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from wsk-files-n1.wilbury.net (wsk-files-n1.wilbury.net [IPv6:2a01:4f9:2a:2851:95:216:42:37]) (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 "svc.wilbury.net", Issuer "E7" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dJRHs5qgbzCSG; Sat, 29 Nov 2025 10:30:01 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (gw-t.owhome.net [87.197.133.183]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id 5D32739189; Sat, 29 Nov 2025 11:29:58 +0100 (CET) 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: freezing on unmountin ext2fs USB device From: Juraj Lutter In-Reply-To: <20251129095452.5905b7d5@hermann> Date: Sat, 29 Nov 2025 11:29:46 +0100 Cc: Warner Losh , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: <0B130A88-42F9-467B-8178-A08C1BB57267@FreeBSD.org> References: <20251123151439.361dd84c@thor.sb211.local> <20251128062140.120e8369@hermann> <20251129095452.5905b7d5@hermann> To: FreeBSD User X-Mailer: Apple Mail (2.3864.200.81.1.6) > On 29. Nov 2025, at 09:59, FreeBSD User = wrote: >=20 > In my case in question it would be >=20 > usbconfig add_dev_quirk_vplh 0x24a9 0x205a 0x0000 0xffff = UQ_MSC_NO_SYNC_CACHE >=20 > right? Right, but it would not survive the reboot. To make it active on boot, put the line: hw.usb.quirk.0=3D"0x24a9 0x205a 0x0000 0xffff UQ_MSC_NO_SYNC_CACHE=E2=80=9D= into /boot/loader.conf =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Sat Nov 29 10:32: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 4dJRLg0SrCz6HX4v for ; Sat, 29 Nov 2025 10:32:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 4dJRLf5mjxz45Cp for ; Sat, 29 Nov 2025 10:32:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-34372216275so2783752a91.2 for ; Sat, 29 Nov 2025 02:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1764412340; x=1765017140; 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=/xAlc9K8ABZ705YgqHF7y4Y7IKkfxtsFj+nG8HdDv6o=; b=2wKLCWLMtdT5TabTSx729zAlBiD1i3w94+M3RKsGhTXD4GfqRcOjqDQsBOuaAR3sZ0 llHg6rvjWsECAFzQo8ux63CQ/mmlJxRvokzu7wLvk/9cVfxeIWQKrcMCVBw0FzC29Fma e3c9Nx8QtaTNwCQVf3aXiVPeApjZ5Yt4uLS988Yi0piG+Fs+WhGbMQ8NmZ4PjidE7Yld Aw1iIYIto1fUpuGn5xVuBV0NBTg0n/DNgjK9HtVwZ//ww81bLp8izZKUQK1RzCMOw7KN P0WgyCC5X3w9WeSMdxsePCsE2PmSDFA850+hYLsZFbUkLY58oCN+gQmseC4xe1Q1BiHq 3LdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764412340; x=1765017140; 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=/xAlc9K8ABZ705YgqHF7y4Y7IKkfxtsFj+nG8HdDv6o=; b=Y/q3Hr35SwrMziEYCkqOQlA2V3yFkygaLBQr8yJBgfXqjub+IeIJZKHqSyDjJoHbfi 0QGAYn5fzUfBftHpR5wyo9UV5b7ItmvsHHy1NRGXcIySpK+V9KMatBNU+p5b5tubQf9G +LFJv4PQrbynmgZUqwhwLBa5yj9D+8NLHlXldiObrk2OmV3Sd9xLCW5MTfWmNDwz/nkD EOIzbZvgzKHS+BVS8CTPDYx9RFxAovop3JyneKCF+/LGS03S+9TeH+afawTDoph8LwCA EAGiY3jqpBW+IvAm6Lc5NHXoWM5xH+zIvzLBvQhsDXHM6Uf+kS7ILCYngHEbkPR4NO28 RzMw== X-Gm-Message-State: AOJu0YyYEGyRsrBMAHPUMzEcJyqmhmvvTO/qcA0hCUx6LZU9aIWwrZ9x BMPNPx9XUWYaaZRP5IjROtKcVwzwvgYmhMGqXqrfMuV/51N+TwifulKsAH61pBXal+dc/b/cICX U034enuyK6i+b9JHoRcm2esgfPyzbl5seSUdMLwuT0Wfwf9cuNHUmrocKuA== X-Gm-Gg: ASbGnctrpJB493etZXj6dECbWhD3/XwweXMVEg2lRN1lCVbcLb9MVGIU6cv7hxJ3e4j Tw8n9qcHwwaW2wkfHey2c7W2c6/CtkyhjWvgsJ332uJSBciOXCsMxTCfzsBnagQFedFoXb8Dmat qgdbFEb4f42UTryUKQg/ZHQdAaRBdjHK2tfGYsfqrv5qzGp9GKJW4ntuWh2xtow3hv6kHWCv/N5 8g9hX0IGFC2NnUVd4BaJmBKELU1TZ/EAsyPHbNkQH1wo7y4O3y5ia6hwnSBl4yqfthMScbPUGH3 JLpSQQ== X-Google-Smtp-Source: AGHT+IHH/Zg0/o7F/VMXY4bq2+/4XZ4vwAMqyEerlxEudADzBIASPwKCYiZHP4mCVOhdXAeLA4i3q4mTiZu99ltXYUg= X-Received: by 2002:a17:90b:4f4c:b0:340:be40:fe0c with SMTP id 98e67ed59e1d1-34733f5c930mr27278108a91.36.1764412340448; Sat, 29 Nov 2025 02:32: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: <20251123151439.361dd84c@thor.sb211.local> <20251128062140.120e8369@hermann> <20251129095452.5905b7d5@hermann> In-Reply-To: <20251129095452.5905b7d5@hermann> From: Warner Losh Date: Sat, 29 Nov 2025 03:32:09 -0700 X-Gm-Features: AWmQ_blng5YeVXMgAAMlCp0k9kO__ixzU7Ur3EK-qcvCinw67nLkto9r_1YdVcU Message-ID: Subject: Re: freezing on unmountin ext2fs USB device To: FreeBSD User Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000ca40500644b9421b" 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: 4dJRLf5mjxz45Cp --000000000000ca40500644b9421b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 29, 2025 at 1:59=E2=80=AFAM FreeBSD User wrote: > On Thu, 27 Nov 2025 23:33:50 -0700 > Warner Losh wrote: > > > On Thu, Nov 27, 2025, 10:22=E2=80=AFPM FreeBSD User > wrote: > > > > > On Tue, 25 Nov 2025 21:03:01 -0700 > > > Warner Losh wrote: > > > > > > > On Sun, Nov 23, 2025 at 7:15=E2=80=AFAM A FreeBSD User < > freebsd@walstatt-de.de> > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > running FreeBSD 16.0-CURRENT #4 master-n282101-c8cf5a99f82b: Sun > Nov 23 > > > > > 13:56:23 CET > > > > > 2025 amd64 I'm running into a serious problem when mounting an > ext2fs > > > > > formated USB Flash > > > > > device (512GB). The devince contains files written by a Linux > system, > > > > > mounting the USB Flash > > > > > via extended4fs, the size of the written datafiles is > 128GB. > Deleting > > > > > those files larger > > > > > than some 20GB results in an I/O error reported by FReeBSD (# sud= o > rm > > > > > /mnt/USB/filename). > > > > > Unmounting the ext2fs after deletion (sudo umount /mnt) results i= n > a > > > total > > > > > freeze of the box. > > > > > No crash, no core dump, nothing. I waited almost an hour hoping f= or > > > > > recover. I have to > > > > > physically switch off the box. > > > > > > > > > > I checked with other USB flash I have at hand, one Samsung 256 GB= , > ZFS > > > - > > > > > no problem, another > > > > > 128GB, UFS, no problem and several much smaller (4 - 64GB) with > FAT or > > > UFS > > > > > filesystems, all no > > > > > problem. > > > > > > > > > > I can not figure out whether it is the USB flash drive itself, > the > > > size or > > > > > the ext2fs itself > > > > > causing the problem. > > > > > > > > > > Does anybody see similar problems or do have an tip to > investigate > > > without > > > > > risking my box' > > > > > health switching it on/off on failure? > > > > > > > > > > > > > I've not seen this on the smaller tests I've been able to run. > > > > > > > > So can you share the error messages that you get when you say you > get I/O > > > > errors? I'd like to see if this is due to an error in ext2fs or on > the > > > USB > > > > drive. It's kinda sounding a little like the particular USB is > triggering > > > > some kind of issue that at the very least we should work around. > Given > > > that > > > > it's not happening on all ext2fs drives you try to access, I'm > leaning > > > > towards the drive, but you never know. > > > > > > > > Thanks > > > > > > Plugging the USB flash gives the following hardware information on th= e > > > console: > > > > > > [...] > > > ugen1.5: at usbus1 > > > umass0 on uhub6 > > > umass0: on usbus1 > > > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 > 00 10 > > > 00 00 > > > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > > > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > > > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 > (Invalid > > > command > > > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable erro= r > > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > > da4: Removable Direct Access SPC-4 SCSI device > > > da4: Serial Number somer serial numbers > > > da4: 400.000MB/s transfers > > > da4: 475000MB (972800000 512 byte sectors) > > > da4: quirks=3D0x2 > > > [...] > > > > > > Trying to mount via: # mount -t ext2fs /dev/da4p1 /mnt/image > > > > > > [...] > > > (da4:umass-sim0:0:0:0): got CAM status 0x444 > > > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > > da4: s/n some serial numbers detached > > > (da4:umass-sim0:0:0:0): Periph destroyed > > > > > > mount: /dev/da4p1: Device not configured > > > > > > > This has the classic hallmarks of a drive that loses its mind on > > SYNCHRONIZE CACHE. Normally, we detect that automatically, but sometime= s > we > > don't. Let's see if this drive is suffering from that. These instructio= ns > > are a bit long, but the shorter ones are harder to explain :). > > > > First, you'll need to find what this drive is. You'll need to use > > "usbconfig -v" to find the drive. Redirect that to a file, then search, > you > > should find something akin to > > > > ugen0.13: > Technology Corp.)> at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5.0Gbps) p= wr=3DON > > (76mA) > > ugen0.13.0: umass1: > > > > The first line might not match, and the numbers will be different. But > > you'll need the vendor and product IDs from this drive. They are a few > > lines later and look akin to the following: > > ... > > idVendor =3D 0x090c > > idProduct =3D 0x1000 > > ... > > You'll find the required output as attachment, desinated usb_asolid.txt. > > The required identifications should be > > idVendor =3D 0x24a9 > idProduct =3D 0x205a > bcdDevice =3D 0x0110 > > > > > > Now, remove the drive and type in the following (with your vendor and > > product replacing mine): > > > > usbconfig add_dev_quirk_vplh 0x090c 0x1000 0x0000 > > 0xffff UQ_MSC_NO_SYNC_CACHE > > In my case in question it would be > > usbconfig add_dev_quirk_vplh 0x24a9 0x205a 0x0000 0xffff > UQ_MSC_NO_SYNC_CACHE > > right? > > > > > This will add a quirk to the usb quirk table. You should see > NO_SYNC_CACHE > > show up in the da4 probe quirk report when you plug the drive back in. > > > > If that fixes it, please let me know. "Hang on close" or "Periph goes > away > > on close" very often is due to this. umount will close the device. I ma= y > > have additional questions for you to help me add a quirk or a heuristic > to > > the code... I'm not yet sure, though, of the correlation to big files. = It > > may be something else, or it may be this. > > Do not see required state change in output: > > [...] > ugen1.5: at usbus1 > umass0 on uhub6 > umass0: on usbus1 > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 1= 0 > 00 00 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > command > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > I would have expected a quirk line for umass0: [911991.296485] umass1 numa-domain 0 on uhub13 [911991.299036] umass1: on usbus0 [911991.305703] umass1: SCSI over Bulk-Only; quirks =3D 0x4000 Is what I get. I don't see the SCSI over Bulk-Only line either in your demsg. I wonder why. I think your device is at 0.6, so something like the following (confirm with usbconfig showing ugen0.4 as this device): usbconfig -d ugen0.6 power_off usbconfig -d ugne0.6 add_quirk UQ_MSC_NO_SYNC_CACHE usbconfig -d ugen0.6 power_on is what I did to generate the umass line above (but with 0.13 instead of 0.6). I wish there was a quirk for REPORT LUNS not being supported, but that warning is harmless. We'll ignore the error and go on to the next thing (I should fix the errors we're just going to ignore when they aren't supported, but I digress). If you can build a kernel, adding USB_DEBUG to it for the duration of testing would give us more information, including the line that I have and that you don't (maybe I should make that unconditional). > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > da4: Removable Direct Access SPC-4 SCSI device > da4: Serial Number 25010993010046 > da4: 400.000MB/s transfers > da4: 475000MB (972800000 512 byte sectors) > da4: quirks=3D0x2 > ugen1.5: at usbus1 (disconnected) > umass0: at uhub6, port 1, addr 4 (disconnected) > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > da4: s/n 25010993010046 detached > (da4:umass-sim0:0:0:0): Periph destroyed > umass0: detached > ugen1.5: at usbus1 > umass0 on uhub6 > umass0: on usbus1 > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 1= 0 > 00 00 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > command > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > da4: Removable Direct Access SPC-4 SCSI device > da4: Serial Number 25010993010046 > da4: 400.000MB/s transfers > da4: 475000MB (972800000 512 byte sectors) > da4: quirks=3D0x2Tryping to mount > > [...] > > Trying to mount /dev/da4p1 (which is the supposed ext4fs/ext2fs partition > on the USB > flash device) results in: > > WARNING: R/W mount denied. Filesystem is not clean - run fsck > > and when trying to solve the problem via > > [...] > # /compat/linux/sbin/fsck.ext4 /dev/da4p1 > e2fsck 1.46.5 (30-Dec-2021) > /compat/linux/sbin/fsck.ext4: No such file or directory while trying to > open /dev/da4p1 > Possibly non-existent device? > > and on console > the following are the only new one? > (da4:umass-sim0:0:0:0): got CAM status 0x444 > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > da4: s/n 25010993010046 detached > (da4:umass-sim0:0:0:0): Periph destroyed > > > I think this special "low cost" device did not only lost its mind, it los= t > its head > also. > Yes. I kinda want to swap you for this: you send it to me and I'll send you one of my happy devices :) Warner > Regards, > > Oliver > > p.s. One note: > > # gpart show -l da4 > =3D> 40 972799920 da4 GPT (464G) > 40 972799920 1 (null) (464G) > > The device in question does have a GPT partition layout. I guess it > doesn't matter here, > but I'll add it anyway for the record. > > > > > Warner > > > > [...] > > > > > > [...] > > > # /compat/linux/sbin/fsck.ext4 /dev/da4p1 > > > e2fsck 1.46.5 (30-Dec-2021) > > > SINA was not cleanly unmounted, check forced. > > > Pass 1: Checking inodes, blocks, and sizes > > > Pass 2: Checking directory structure > > > Pass 3: Checking directory connectivity > > > Pass 4: Checking reference counts > > > Pass 5: Checking group summary information > > > Error writing file system info: Invalid argument > > > > > > XXXX: ***** FILE SYSTEM WAS MODIFIED ***** > > > > > > [...] > > > > > > detaching and attaching to another USB slot on the same (external) HU= B: > > > > > > [...] > > > ugen1.5: at usbus1 > > > umass0 on uhub6 > > > umass0: on usbus1 > > > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 > 00 10 > > > 00 00 > > > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > > > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > > > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 > (Invalid > > > command > > > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable erro= r > > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > > da4: Removable Direct Access SPC-4 SCSI device > > > da4: Serial Number some serial numbers > > > da4: 400.000MB/s transfers > > > da4: 475000MB (972800000 512 byte sectors) > > > da4: quirks=3D0x2 > > > linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback fd=3D3, > cmd=3D0x127c > > > ('\^R',124) is > > > not implemented linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallba= ck > > > fd=3D3, cmd=3D0x125e > > > ('\^R',94) is not implemented (da4:umass-sim0:0:0:0): got CAM status > 0x444 > > > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > > da4: s/n some serial numbers detached > > > (da4:umass-sim0:0:0:0): Periph destroyed > > > > > > [...] > > > > > > I can not even mount the device on CURRENT (FreeBSD 16.0-CURRENT #1 > > > master-n282217-34d66b0c96d5: Fri Nov 28 05:15:56 CET 2025 amd64). > > > > > > Package used for linux operation: emulators/linux-rl9 > > > > > --000000000000ca40500644b9421b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Nov 29,= 2025 at 1:59=E2=80=AFAM FreeBSD User <freebsd@walstatt-de.de> wrote:
On Thu, 27 Nov 2025 23:33:50 -0700
Warner Losh <imp@bsd= imp.com> wrote:

> On Thu, Nov 27, 2025, 10:22=E2=80=AFPM FreeBSD User <freebsd@walstatt-de.de>= ; wrote:
>
> > On Tue, 25 Nov 2025 21:03:01 -0700
> > Warner Losh <imp@bsdimp.com> wrote:
> >=C2=A0
> > > On Sun, Nov 23, 2025 at 7:15=E2=80=AFAM A FreeBSD User <<= a href=3D"mailto:freebsd@walstatt-de.de" target=3D"_blank">freebsd@walstatt= -de.de>
> > > wrote:
> > >=C2=A0
> > > > Hello,
> > > >
> > > > running FreeBSD 16.0-CURRENT #4 master-n282101-c8cf5a99= f82b: Sun Nov 23
> > > > 13:56:23 CET
> > > > 2025 amd64 I'm running into a serious problem when = mounting an ext2fs
> > > > formated USB Flash
> > > > device (512GB). The devince contains files written by a= Linux system,
> > > > mounting the USB Flash
> > > > via extended4fs, the size of the written datafiles is &= gt; 128GB. Deleting
> > > > those files larger
> > > > than some 20GB results in an I/O error reported by FRee= BSD (# sudo rm
> > > > /mnt/USB/filename).
> > > > Unmounting the ext2fs after deletion (sudo umount /mnt)= results in a=C2=A0
> > total=C2=A0
> > > > freeze of the box.
> > > > No crash, no core dump, nothing. I waited almost an hou= r hoping for
> > > > recover. I have to
> > > > physically switch off the box.
> > > >
> > > > I checked with other USB flash I have at hand, one Sams= ung 256 GB, ZFS=C2=A0
> > -=C2=A0
> > > > no problem, another
> > > > 128GB, UFS, no problem and several much smaller (4 - 64= GB) with FAT or=C2=A0
> > UFS=C2=A0
> > > > filesystems, all no
> > > > problem.
> > > >
> > > > I can not figure out whether it is the USB flash drive = itself, the=C2=A0
> > size or=C2=A0
> > > > the ext2fs itself
> > > > causing the problem.
> > > >
> > > > Does anybody see similar problems or do have an tip to = investigate=C2=A0
> > without=C2=A0
> > > > risking my box'
> > > > health switching it on/off on failure?
> > > >=C2=A0
> > >
> > > I've not seen this on the smaller tests I've been ab= le to run.
> > >
> > > So can you share the error messages that you get when you sa= y you get I/O
> > > errors? I'd like to see if this is due to an error in ex= t2fs or on the=C2=A0
> > USB=C2=A0
> > > drive. It's kinda sounding a little like the particular = USB is triggering
> > > some kind of issue that at the very least we should work aro= und. Given=C2=A0
> > that=C2=A0
> > > it's not happening on all ext2fs drives you try to acces= s, I'm leaning
> > > towards the drive, but you never know.
> > >
> > > Thanks=C2=A0
> >
> > Plugging the USB flash gives the following hardware information o= n the
> > console:
> >
> > [...]
> > ugen1.5: <ASolid USB> at usbus1
> > umass0 on uhub6
> > umass0: <ASolid USB, class 0/0, rev 3.20/1.10, addr 4> on u= sbus1
> > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00= 00 00 10
> > 00 00
> > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
> > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition
> > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (= Invalid
> > command
> > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable = error
> > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
> > da4: <ASolid USB > Removable Direct Access SPC-4 SCSI devic= e
> > da4: Serial Number somer serial numbers
> > da4: 400.000MB/s transfers
> > da4: 475000MB (972800000 512 byte sectors)
> > da4: quirks=3D0x2<NO_6_BYTE>
> > [...]
> >
> > Trying to mount via:=C2=A0 # mount -t ext2fs /dev/da4p1 /mnt/imag= e
> >
> > [...]
> > (da4:umass-sim0:0:0:0): got CAM status 0x444
> > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
> > da4: <ASolid USB >=C2=A0 s/n some serial numbers=C2=A0 deta= ched
> > (da4:umass-sim0:0:0:0): Periph destroyed
> >
> > mount: /dev/da4p1: Device not configured
> >=C2=A0
>
> This has the classic hallmarks of a drive that loses its mind on
> SYNCHRONIZE CACHE. Normally, we detect that automatically, but sometim= es we
> don't. Let's see if this drive is suffering from that. These i= nstructions
> are a bit long, but the shorter ones are harder to explain :).
>
> First, you'll need to find what this drive is. You'll need to = use
> "usbconfig -v" to find the drive. Redirect that to a file, t= hen search, you
> should find something akin to
>
> ugen0.13: <Flash Drive Silicon Motion, Inc. - Taiwan (formerly Feiy= a
> Technology Corp.)> at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5.0Gbp= s) pwr=3DON
> (76mA)
> ugen0.13.0: umass1: <ASolid USB, class 0/0, rev 3.00/11.00, addr 12= >
>
> The first line might not match, and the numbers will be different. But=
> you'll need the vendor and product IDs from this drive. They are a= few
> lines later and look akin to the following:
> ...
>=C2=A0 =C2=A0idVendor =3D 0x090c
>=C2=A0 =C2=A0idProduct =3D 0x1000
> ...

You'll find the required output as attachment, desinated usb_asolid.txt= .

The required identifications should be

=C2=A0 idVendor =3D 0x24a9
=C2=A0 idProduct =3D 0x205a
=C2=A0 bcdDevice =3D 0x0110


>
> Now, remove the drive and type in the following (with your vendor and<= br> > product replacing mine):
>
> usbconfig add_dev_quirk_vplh 0x090c 0x1000 0x0000
> 0xffff UQ_MSC_NO_SYNC_CACHE

In my case in question it would be

usbconfig add_dev_quirk_vplh 0x24a9 0x205a 0x0000 0xffff UQ_MSC_NO_SYNC_CAC= HE

right?

>
> This will add a quirk to the usb quirk table. You should see NO_SYNC_C= ACHE
> show up in the da4 probe quirk report when you plug the drive back in.=
>
> If that fixes it, please let me know. "Hang on close" or &qu= ot;Periph goes away
> on close" very often is due to this. umount will close the device= . I may
> have additional questions for you to help me add a quirk or a heuristi= c to
> the code... I'm not yet sure, though, of the correlation to big fi= les. It
> may be something else, or it may be this.

Do not see required state change in output:

[...]
ugen1.5: <ASolid USB> at usbus1
umass0 on uhub6
umass0: <ASolid USB, class 0/0, rev 3.20/1.10, addr 4> on usbus1
(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 = 00 00
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid co= mmand
operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error
<= /blockquote>

I would have expected a quirk line for umas= s0:

[911991.296485] umass1 numa-domain 0 on uhub13
[= 911991.299036] umass1: <Samsung Flash Drive, class 0/0, rev 3.00/11.00, = addr 12> on usbus0
[911991.305703] umass1: =C2=A0SCSI over Bulk-Only;= quirks =3D 0x4000<NO_SYNCHRONIZE_CACHE>

Is wh= at I get. I don't see the SCSI over Bulk-Only line either in your demsg= . I wonder why.

I think your device is at 0.6, so = something like the following (confirm with usbconfig showing ugen0.4 as thi= s device):

usbconfig -d ugen0.6 power_off
usbconfig -d ugne0.6 add_quirk UQ_MSC_NO_SYNC_CACHE
usbconfig -= d ugen0.6 power_on

is what I did to generate the u= mass line above (but with 0.13 instead of 0.6). I wish there was a quirk fo= r REPORT LUNS not being supported, but that warning is harmless. We'll = ignore the error and go on to the next thing (I should fix the errors we= 9;re just going to ignore when they aren't supported, but I digress). I= f you can build a kernel, adding USB_DEBUG to it for the duration of testin= g would give us more information, including the line that I have and that y= ou don't (maybe I should make that unconditional).
=C2=A0
da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
da4: <ASolid USB > Removable Direct Access SPC-4 SCSI device
da4: Serial Number 25010993010046
da4: 400.000MB/s transfers
da4: 475000MB (972800000 512 byte sectors)
da4: quirks=3D0x2<NO_6_BYTE>
ugen1.5: <ASolid USB> at usbus1 (disconnected)
umass0: at uhub6, port 1, addr 4 (disconnected)
da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
da4: <ASolid USB >=C2=A0 s/n 25010993010046 detached
(da4:umass-sim0:0:0:0): Periph destroyed
umass0: detached
ugen1.5: <ASolid USB> at usbus1
umass0 on uhub6
umass0: <ASolid USB, class 0/0, rev 3.20/1.10, addr 5> on usbus1
(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 = 00 00
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid co= mmand
operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error
da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
da4: <ASolid USB > Removable Direct Access SPC-4 SCSI device
da4: Serial Number 25010993010046
da4: 400.000MB/s transfers
da4: 475000MB (972800000 512 byte sectors)
da4: quirks=3D0x2<NO_6_BYTE>Tryping to mount

[...]

Trying to mount /dev/da4p1 (which is the supposed ext4fs/ext2fs partition o= n the USB
flash device) results in:

WARNING: R/W mount denied.=C2=A0 Filesystem is not clean - run fsck

and when trying to solve the problem via

[...]
# /compat/linux/sbin/fsck.ext4 /dev/da4p1
e2fsck 1.46.5 (30-Dec-2021)
/compat/linux/sbin/fsck.ext4: No such file or directory while trying to ope= n /dev/da4p1
Possibly non-existent device?

and on console

the following are the on= ly new one?
=C2=A0
(da4:umass-sim0:0:0:0): got CAM status 0x444
(da4:umass-sim0:0:0:0): fatal error, failed to attach to device
da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
da4: <ASolid USB >=C2=A0 s/n 25010993010046 detached
(da4:umass-sim0:0:0:0): Periph destroyed


I think this special "low cost" device did not only lost its mind= , it lost its head
also.

Yes. I kinda want to swap you for= this: you send it to me and I'll send you one of my happy devices :)

Warner
=C2=A0
Regards,

Oliver

p.s. One note:

# gpart show -l da4
=3D>=C2=A0 =C2=A0 =C2=A0 =C2=A040=C2=A0 972799920=C2=A0 da4=C2=A0 GPT=C2= =A0 (464G)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A040=C2=A0 972799920=C2=A0 =C2=A0 1=C2=A0 (= null)=C2=A0 (464G)

The device in question does have a GPT partition layout. I guess it doesn&#= 39;t matter here,
but I'll add it anyway for the record.

>
> Warner
>
> [...]
> >
> > [...]
> > # /compat/linux/sbin/fsck.ext4 /dev/da4p1
> > e2fsck 1.46.5 (30-Dec-2021)
> > SINA was not cleanly unmounted, check forced.
> > Pass 1: Checking inodes, blocks, and sizes
> > Pass 2: Checking directory structure
> > Pass 3: Checking directory connectivity
> > Pass 4: Checking reference counts
> > Pass 5: Checking group summary information
> > Error writing file system info: Invalid argument
> >
> > XXXX: ***** FILE SYSTEM WAS MODIFIED *****
> >
> > [...]
> >
> > detaching and attaching to another USB slot on the same (external= ) HUB:
> >
> > [...]
> > ugen1.5: <ASolid USB> at usbus1
> > umass0 on uhub6
> > umass0: <ASolid USB, class 0/0, rev 3.20/1.10, addr 6> on u= sbus1
> > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00= 00 00 10
> > 00 00
> > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
> > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition
> > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (= Invalid
> > command
> > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable = error
> > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
> > da4: <ASolid USB > Removable Direct Access SPC-4 SCSI devic= e
> > da4: Serial Number some serial numbers
> > da4: 400.000MB/s transfers
> > da4: 475000MB (972800000 512 byte sectors)
> > da4: quirks=3D0x2<NO_6_BYTE>
> > linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback fd=3D3, c= md=3D0x127c
> > ('\^R',124) is
> > not implemented linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fa= llback
> > fd=3D3, cmd=3D0x125e
> > ('\^R',94) is not implemented (da4:umass-sim0:0:0:0): got= CAM status 0x444
> > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0
> > da4: <ASolid USB >=C2=A0 s/n some serial numbers detached > > (da4:umass-sim0:0:0:0): Periph destroyed
> >
> > [...]
> >
> > I can not even mount the device on CURRENT (FreeBSD 16.0-CURRENT = #1
> > master-n282217-34d66b0c96d5: Fri Nov 28 05:15:56 CET 2025 amd64).=
> >
> > Package used for linux operation: emulators/linux-rl9
> >=C2=A0

--000000000000ca40500644b9421b-- From nobody Sat Nov 29 10:32: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 4dJRMV2XK9z6HX7k for ; Sat, 29 Nov 2025 10:33:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 4dJRMT3kRBz45vl for ; Sat, 29 Nov 2025 10:33:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-343684a06b2so2519218a91.1 for ; Sat, 29 Nov 2025 02:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1764412383; x=1765017183; 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=uN6D6zJaL5eYoeQ30x1iQJAR3uqe2eNE9c9W+H/Qa94=; b=GioBdUUsRXKYT9WCoP1Utr+bmb+le7i12tIv1J0/ZezlCLtACn6QRgNQCCvMH3jWQy jVBQRObw7jNZQCWG35ZmmSYkGqKQ9j4PFW0K9NZHfg6lKXkRBhmKC9865USES3g3RP/E 1k4+t/We/gQNWJMBL5V1Kn+1bRuIoXcarFvNGhrzCC2V9sbHtDCtj4vedJSgA9Q3NzBO WP0vYXO4XFtqIE1Mfcq6TatAef3LNVlmemMH3mlsXp9jtI0uI0rvsgDPtptZkuLmaNQe 41M+M2Bw9ClqNE3wUuFrszEk0iLpmoHXW6e0gXWyzufJaTRb5lUhHXoHlQVX+DWxfxb+ BLVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764412383; x=1765017183; 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=uN6D6zJaL5eYoeQ30x1iQJAR3uqe2eNE9c9W+H/Qa94=; b=ali9lsH5PWBJnYSFEjfBJ/4pIYtBKJFCJQ3WKYw6APO7G/jY6GNvmaVs7SFKsWyuyM WUbyiQ0Ml5PuT59pKI5ADRoXFWCk5s5+JOMCuPdyo88WvFQcRHwieGLsVzcyGRcesS+C 4q06AM2GAtDaj4IBrn5x6OmUhfvsvUqCheLU5vmjgaw5+6rpPkqnkUWDh6NbEonWcX6w M+2anNZvEU83Z3Xlfln89AMqbWRVbfToDNXR3smKaQ7U9x484/9Ls50mmuBd/XLwUXgf M/i5hKyWl6eHX3k2Rye3FPt2BQelfwM5upqjIT5Ap/1q6BIimZGjQuvqAwvw/zePcC20 rjZg== X-Forwarded-Encrypted: i=1; AJvYcCX8/JqHWKPmd591pT/LE11xYMXkJmWK5xZiQYnLu+0IxNThpc/FwvubFTEGmuBrzVSgPGNofJTgnxyQD7yTq50=@freebsd.org X-Gm-Message-State: AOJu0YwOZzVEwPzm+ybRgBTrWbWIQ7mJ0PMv0uj0RojsAu/H5I+Iy6J+ SFQ2W3pQu+PCtbK9wQGUKoVsY8o13A/MmhqhjmU6doKYDJJI/0ui5/yXPCzRsTtUZxRknPWXY3P eOOxkFh2bf7881mS5OQvX0C1bFptiqFC2v8shiK850g== X-Gm-Gg: ASbGncuP/2dZ7NOOPlroIOd97hhnXd5T0c/z2r2mDY8on4+e9DdwYe1EI6adTTo7KEU JEZX29P3PrYvnYRlZxovhzpD3hh6sCjQrxdLEdfKdSHKyne7bbOFLbhbC2epoNHGGABQwB83U+/ /PAqqxH6tdXnHNsb1ZYuwxLo6Zs+ACopc8XCs1U5aay7KdjdIhw02ePTZYtwYHn8JsIZ8gSRS5J QOwDMUaqT9ikZKfifnogAaOkKNcimU4PA7aIPEc+/x1uSVsjj+IIx2rZ8+OKRPH12BnWEY= X-Google-Smtp-Source: AGHT+IHwVu9ZwXtVNnkWXesEqFcgYDwqjvvAJBS+pgry4rJWnfRERiCsobpbza2qn6SmjvurgPrGLPnhq5wfSaXTEaw= X-Received: by 2002:a17:90b:38c7:b0:340:ec6f:5ac5 with SMTP id 98e67ed59e1d1-34733e55021mr26125077a91.2.1764412383093; Sat, 29 Nov 2025 02:33: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: <20251123151439.361dd84c@thor.sb211.local> <20251128062140.120e8369@hermann> <20251129095452.5905b7d5@hermann> <0B130A88-42F9-467B-8178-A08C1BB57267@FreeBSD.org> In-Reply-To: <0B130A88-42F9-467B-8178-A08C1BB57267@FreeBSD.org> From: Warner Losh Date: Sat, 29 Nov 2025 03:32:52 -0700 X-Gm-Features: AWmQ_blw5FzIl3K9nK3SB4tmzrhtfPLjIwsMEwTaju2nia1EjlWl2FNATbg3exw Message-ID: Subject: Re: freezing on unmountin ext2fs USB device To: Juraj Lutter Cc: FreeBSD User , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="00000000000054f1b70644b945c2" 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: 4dJRMT3kRBz45vl --00000000000054f1b70644b945c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 29, 2025 at 3:30=E2=80=AFAM Juraj Lutter wro= te: > > > > On 29. Nov 2025, at 09:59, FreeBSD User wrote: > > > > In my case in question it would be > > > > usbconfig add_dev_quirk_vplh 0x24a9 0x205a 0x0000 0xffff > UQ_MSC_NO_SYNC_CACHE > > > > right? > > Right, but it would not survive the reboot. > > To make it active on boot, put the line: > > hw.usb.quirk.0=3D"0x24a9 0x205a 0x0000 0xffff UQ_MSC_NO_SYNC_CACHE=E2=80= =9D > > into /boot/loader.conf > Indeed. I wanted to make sure it was working before that step. It doesn't seem like this is the ticket. Warner --00000000000054f1b70644b945c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Nov 29,= 2025 at 3:30=E2=80=AFAM Juraj Lutter <otis@freebsd.org> wrote:


> On 29. Nov 2025, at 09:59, FreeBSD User <freebsd@walstatt-de.de> wrote:
>
> In my case in question it would be
>
> usbconfig add_dev_quirk_vplh 0x24a9 0x205a 0x0000 0xffff UQ_MSC_NO_SYN= C_CACHE
>
> right?

Right, but it would not survive the reboot.

To make it active on boot, put the line:

hw.usb.quirk.0=3D"0x24a9 0x205a 0x0000 0xffff UQ_MSC_NO_SYNC_CACHE=E2= =80=9D

into /boot/loader.conf

Indeed. I wanted= to make sure it was working before that step. It doesn't seem like thi= s is the ticket.

Warner=C2=A0
--00000000000054f1b70644b945c2-- From nobody Sat Nov 29 11:24:18 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 4dJSVp5m7Lz6HdTQ for ; Sat, 29 Nov 2025 11:24:34 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4dJSVn2Dzvz3CwY for ; Sat, 29 Nov 2025 11:24:33 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=YvUJLQMQ; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 17E18240113; Sat, 29 Nov 2025 12:24:21 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 57C2B2402E8; Sat, 29 Nov 2025 12:24:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764415459; 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=1aHA7c2UZXcx9sfON2wbYUAlwkuTDNvCZcqHorR+J0Q=; b=YvUJLQMQi6OZDqAvZsfiJgXVF1NfZe8XLQXxVkRHeedljOgBMF06wh5ofJ7sN04e8LH4jO Dgsvh4CrxmFrBr5kwNQKJTMZE/hv5KzcFQAurHKWMPZFu1ZrqOz5Q4XpRqMAvkQzwvVBrI Ueat1m+QCcloX2iR/FSGLctFTXatQ9Z++hZ2YSp/WkPGWUG2LA7o6bP3A97dBeVBW9TzOX B3lstboA9r+ubiUN4UlOoHw45JT4VNZVioLJPNrz+BbNcGLAwsnPh0SFyXENrIjOeS+YWV Z2LZNQ3H+UsMZcNobRWsKnRnwizf5srzLoP8Pxyv0UTmGkZnBIkY342JKKtuOQ== Received: from hermann (dynamic-2a02-3100-23f0-d502-33d6-a71c-2660-5263.310.pool.telefonica.de [IPv6:2a02:3100:23f0:d502:33d6:a71c:2660:5263]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 08E42240123; Sat, 29 Nov 2025 12:24:18 +0100 (CET) Date: Sat, 29 Nov 2025 12:24:18 +0100 From: FreeBSD User To: Ronald Klop Cc: FreeBSD CURRENT Subject: Re: 15-STABLE: dhclient fails on em0 (Lenovo T580) Message-ID: <20251129121649.49441eff@hermann> In-Reply-To: <636185594.3615.1764323768736@localhost> References: <20251128082630.3dbea678@hermann> <817794595.3413.1764321375872@localhost> <20251128105016.28b5562a@hermann> <636185594.3615.1764323768736@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: multipart/mixed; boundary="MP_/W_I_34BVXS2S2tDXNX6AolW" X-Rspamd-UID: 61c8ce X-Rspamd-UID: c53d70 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MIME_UNKNOWN(0.10)[text/x-log]; DMARC_NA(0.00)[walstatt-de.de]; MIME_TRACE(0.00)[0:+,1:+,2:~,3:~]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4dJSVn2Dzvz3CwY --MP_/W_I_34BVXS2S2tDXNX6AolW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, 28 Nov 2025 10:56:08 +0100 (CET) Ronald Klop wrote: > Ok. > > Can you copy paste the console output of the booting system up until the login prompt? > Or setup /var/log/console.log via /etc/syslog.conf and share that output. Please find the requested output of syslog (set to console.debug) attached as well as a /var/log/message extract. > > Regards, > Ronald. > > > Van: FreeBSD User > Datum: vrijdag, 28 november 2025 10:50 > Aan: Ronald Klop > CC: FreeBSD CURRENT > Onderwerp: Re: 15-STABLE: dhclient fails on em0 (Lenovo T580) > > > > On Fri, 28 Nov 2025 10:16:15 +0100 (CET) > > Ronald Klop wrote: > > > > > It might be a typo in your mail, but it might also be the cause of your issue. > > > This config needs to be in /etc/rc.conf, not in /etc/src.conf as you state in your > > > mail. > > > > > > Regards, > > > Ronald. > > > > Sorry, a typo. > > > > > > > > > > > Van: FreeBSD User > > > Datum: vrijdag, 28 november 2025 08:26 > > > Aan: FreeBSD CURRENT > > > Onderwerp: 15-STABLE: dhclient fails on em0 (Lenovo T580) > > > > > > > > I recently switched from FreeBSD 14-STABLE to 15-STABLE (after branching of > > > > 16-CURRENT) on my working laptop, physically a Lenovo T580. Its LAN NIC FreeBSD > > > > recognizes as em0 (see below). System is at: 15.0-STABLE #16 > > > > stable/15-n281349-b903f27e171b: Fri Nov 28 05:20:32 CET 2025 amd64. Kernel config: > > > > GENERIC. Configuration has been setup and renewed acording to changes, consider > > > > the system as a fresh install. > > > > > > > > Problem: em0 never gets an IPv4 via DHCP on startup (init process via rc.conf). > > > > > > > > Configured in /etc/src.conf: > > > > [... WORKAROUND ...] > > > > netwait_enable="NO" > > > > netwait_if="em0" > > > > [...] > > > > > > > > and on a regular basis: > > > > [...] > > > > ifconfig_em0="DHCP" > > > > ifconfig_em0_ipv6="inet6 accept_rtadv -ifdisabled nud -no_radr auto_linklocal" > > > > [...] > > > > > > > > Very strange: after a final boot up, its very easy to require and achive an IPv4 > > > > with > > > > > > > > dhclient em0 > > > > > > > > I'm out of ideas ... > > > > > > > > > > > > > > > > > > > > > > > > ==== > > > > pciconf: > > > > [...] > > > > em0@pci0:0:31:6: class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 > > > > device=0x15d8 subvendor=0x17aa subdevice=0x225a vendor = 'Intel Corporation' > > > > device = 'Ethernet Connection (4) I219-V' > > > > class = network > > > > subclass = ethernet > > > > bar [10] = type Memory, range 32, base 0xe8200000, size 131072, enabled > > > > cap 01[c8] = powerspec 3 supports D0 D3 current D0 > > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > > > cap 13[e0] = PCI Advanced Features: FLR TP > > > > > > > > [...] > > > > > > > > dmesg: > > > > ichsmb0: port 0xefa0-0xefbf mem > > > > 0xe8253000-0xe82530ff at device 31.4 on pci0 em0: mem > > > > 0xe8200000-0xe821ffff at device 31.6 on pci0 em0: EEPROM V0.1-3 > > > > em0: Using 1024 TX descriptors and 1024 RX descriptors > > > > em0: Using an MSI interrupt > > > > em0: Ethernet address: 48:2a:e3:3a:cf:52 > > > > em0: netmap queues/slots: TX 1/1024, RX 1/1024 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --MP_/W_I_34BVXS2S2tDXNX6AolW Content-Type: application/octet-stream; name=messages Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=messages Tm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiAtLS08PEJPT1Q+Pi0tLQpOb3Yg MjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IENvcHlyaWdodCAoYykgMTk5Mi0yMDI1 IFRoZSBGcmVlQlNEIFByb2plY3QuCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5l bDogQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkx LCAxOTkyLCAxOTkzLCAxOTk0Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog CVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMg cmVzZXJ2ZWQuCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogRnJlZUJTRCBp cyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCk5vdiAy OSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogRnJlZUJTRCAxNS4wLVNUQUJMRSAjMjEg c3RhYmxlLzE1LW4yODEzNjAtNmJkYTM2NTViODI3OiBTYXQgTm92IDI5IDEwOjQ4OjU4IENFVCAy MDI1Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogICAgIHJvb3RAaGVybWFu bjovdXNyL29iai91c3Ivc3JjL2FtZDY0LmFtZDY0L3N5cy9IRVJNQU5OIGFtZDY0Ck5vdiAyOSAx MTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogRnJlZUJTRCBjbGFuZyB2ZXJzaW9uIDE5LjEu NyAoaHR0cHM6Ly9naXRodWIuY29tL2xsdm0vbGx2bS1wcm9qZWN0LmdpdCBsbHZtb3JnLTE5LjEu Ny0wLWdjZDcwODAyOWUwYjIpCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog VlQoZWZpZmIpOiByZXNvbHV0aW9uIDE5MjB4MTA4MApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVy bWFubiBrZXJuZWw6IENQVSBtaWNyb2NvZGU6IG5vIG1hdGNoaW5nIHVwZGF0ZSBmb3VuZApOb3Yg MjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IENQVTogSW50ZWwoUikgQ29yZShUTSkg aTctODU1MFUgQ1BVIEAgMS44MEdIeiAoMjAwMC4wMC1NSHogSzgtY2xhc3MgQ1BVKQpOb3YgMjkg MTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6ICAgT3JpZ2luPSJHZW51aW5lSW50ZWwiICBJ ZD0weDgwNmVhICBGYW1pbHk9MHg2ICBNb2RlbD0weDhlICBTdGVwcGluZz0xMApOb3YgMjkgMTE6 MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6ICAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1F LERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBB VCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+ Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogICBGZWF0dXJlczI9MHg3ZmZh ZmJiZjxTU0UzLFBDTE1VTFFEUSxEVEVTNjQsTU9OLERTX0NQTCxWTVgsRVNULFRNMixTU1NFMyxT REJHLEZNQSxDWDE2LHhUUFIsUERDTSxQQ0lELFNTRTQuMSxTU0U0LjIseDJBUElDLE1PVkJFLFBP UENOVCxUU0NETFQsQUVTTkksWFNBVkUsT1NYU0FWRSxBVlgsRjE2QyxSRFJBTkQ+Ck5vdiAyOSAx MTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogICBBTUQgRmVhdHVyZXM9MHgyYzEwMDgwMDxT WVNDQUxMLE5YLFBhZ2UxR0IsUkRUU0NQLExNPgpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFu biBrZXJuZWw6ICAgQU1EIEZlYXR1cmVzMj0weDEyMTxMQUhGLEFCTSxQcmVmZXRjaD4KTm92IDI5 IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiAgIFN0cnVjdHVyZWQgRXh0ZW5kZWQgRmVh dHVyZXM9MHgyOWM2N2FmPEZTR1NCQVNFLFRTQ0FESixTR1gsQk1JMSxBVlgyLFNNRVAsQk1JMixF Uk1TLElOVlBDSUQsTkZQVVNHLE1QWCxSRFNFRUQsQURYLFNNQVAsQ0xGTFVTSE9QVCxQUk9DVFJB Q0U+Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogICBTdHJ1Y3R1cmVkIEV4 dGVuZGVkIEZlYXR1cmVzMz0weGJjMDAyZTAwPE1DVU9QVCxNRF9DTEVBUixUU1hGQSxJQlBCLFNU SUJQLEwxREZMLEFSQ0hfQ0FQLFNTQkQ+Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtl cm5lbDogICBYU0FWRSBGZWF0dXJlcz0weGY8WFNBVkVPUFQsWFNBVkVDLFhJTlVTRSxYU0FWRVM+ Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogICBJQTMyX0FSQ0hfQ0FQUz0w eGEwMDBjMDQ8UlNCQT4KTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiAgIFZU LXg6IFBBVCxITFQsTVRGLFBBVVNFLEVQVCxVRyxWUElECk5vdiAyOSAxMTozNjowMCA8MC4yPiBo ZXJtYW5uIGtlcm5lbDogICBUU0M6IFAtc3RhdGUgaW52YXJpYW50LCBwZXJmb3JtYW5jZSBzdGF0 aXN0aWNzCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogcmVhbCBtZW1vcnkg ID0gMTcxNzk4NjkxODQgKDE2Mzg0IE1CKQpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBr ZXJuZWw6IGF2YWlsIG1lbW9yeSA9IDE2NTEwOTY3ODA4ICgxNTc0NiBNQikKTm92IDI5IDExOjM2 OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBFdmVudCB0aW1lciAiTEFQSUMiIHF1YWxpdHkgNjAw Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogQUNQSSBBUElDIFRhYmxlOiA8 TEVOT1ZPIFRQLU4yNyAgPgpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IEZy ZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDggQ1BVcwpOb3YgMjkg MTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IEZyZWVCU0QvU01QOiAxIHBhY2thZ2Uocykg eCA0IGNvcmUocykgeCAyIGhhcmR3YXJlIHRocmVhZHMKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhl cm1hbm4ga2VybmVsOiByYW5kb206IHJlZ2lzdGVyaW5nIGZhc3Qgc291cmNlIEludGVsIFNlY3Vy ZSBLZXkgU2VlZApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHJhbmRvbTog ZmFzdCBwcm92aWRlcjogIkludGVsIFNlY3VyZSBLZXkgU2VlZCIKTm92IDI5IDExOjM2OjAwIDww LjI+IGhlcm1hbm4ga2VybmVsOiByYW5kb206IHVuYmxvY2tpbmcgZGV2aWNlLgpOb3YgMjkgMTE6 MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IFNlY3VyaXR5IHBvbGljeSBsb2FkZWQ6IE1BQy9k byAobWFjX2RvKQpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IFNlY3VyaXR5 IHBvbGljeSBsb2FkZWQ6IE1BQy9udHBkIChtYWNfbnRwZCkKTm92IDI5IDExOjM2OjAwIDwwLjI+ IGhlcm1hbm4ga2VybmVsOiBpb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTExOQpOb3YgMjkg MTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IExhdW5jaGluZyBBUHM6IDEgMyA0IDYgNyA1 IDIKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBUQ1AgSHB0cyBjcmVhdGVk IDggc3dpIGludGVycnVwdCB0aHJlYWRzIGFuZCBib3VuZCAwIHRvIGNwdXMKTm92IDI5IDExOjM2 OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBDdXNlIHYwLjEuMzcgQCAvZGV2L2N1c2UKTm92IDI5 IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiByYW5kb206IGVudHJvcHkgZGV2aWNlIGV4 dGVybmFsIGludGVyZmFjZQpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGti ZDEgYXQga2JkbXV4MApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGVmaXJ0 YzA6IDxFRkkgUmVhbHRpbWUgQ2xvY2s+Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtl cm5lbDogZWZpcnRjMDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrLCByZXNvbHV0 aW9uIDEuMDAwMDAwcwpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHNtYmlv czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBCSU9TPiBhdCBpb21lbSAweDc4NmQ2MDAwLTB4Nzg2ZDYw MTcKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBzbWJpb3MwOiBFbnRyeSBw b2ludDogdjMgKDY0LWJpdCksIFZlcnNpb246IDMuMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVy bWFubiBrZXJuZWw6IGFlc25pMDogPEFFUy1DQkMsQUVTLUNDTSxBRVMtR0NNLEFFUy1JQ00sQUVT LVhUUz4KTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBhY3BpMDogPExFTk9W TyBUUC1OMjc+Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogYWNwaV9lYzA6 IDxFbWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxNiwgRUNEVD4gcG9ydCAweDYyLDB4NjYgb24g YWNwaTAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBhY3BpMDogUG93ZXIg QnV0dG9uIChmaXhlZCkKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBjcHUw OiA8QUNQSSBDUFU+IG9uIGFjcGkwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5l bDogaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0w eGZlZDAwM2ZmIG9uIGFjcGkwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog VGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAyNDAwMDAwMCBIeiBxdWFsaXR5IDk1MApOb3Yg MjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IEV2ZW50IHRpbWVyICJIUEVUIiBmcmVx dWVuY3kgMjQwMDAwMDAgSHogcXVhbGl0eSA1NTAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1h bm4ga2VybmVsOiBhdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzcgaXJx IDggb24gYWNwaTAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBhdHJ0YzA6 IFdhcm5pbmc6IENvdWxkbid0IG1hcCBJL08uCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5u IGtlcm5lbDogYXRydGMwOiByZWdpc3RlcmVkIGFzIGEgdGltZS1vZi1kYXkgY2xvY2ssIHJlc29s dXRpb24gMS4wMDAwMDBzCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogRXZl bnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMApOb3YgMjkgMTE6MzY6 MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGF0dGltZXIwOiA8QVQgdGltZXI+IHBvcnQgMHg0MC0w eDQzLDB4NTAtMHg1MyBpcnEgMCBvbiBhY3BpMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFu biBrZXJuZWw6IFRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0 eSAwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogRXZlbnQgdGltZXIgImk4 MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMApOb3YgMjkgMTE6MzY6MDAgPDAu Mj4gaGVybWFubiBrZXJuZWw6IFRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5 NTQ1IEh6IHF1YWxpdHkgOTAwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog YWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHgxODA4LTB4 MTgwYiBvbiBhY3BpMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHBjaWIw OiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKTm92IDI5 IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHZnYXBjaTA6IDxWR0Et Y29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4ZTAwMC0weGUwM2YgbWVtIDB4ZTcwMDAwMDAtMHhl N2ZmZmZmZiwweGMwMDAwMDAwLTB4Y2ZmZmZmZmYgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCk5vdiAy OSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogdmdhcGNpMDogQm9vdCB2aWRlbyBkZXZp Y2UKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiB4aGNpMDogPEludGVsIFN1 bnJpc2UgUG9pbnQtTFAgVVNCIDMuMCBjb250cm9sbGVyPiBtZW0gMHhlODIyMDAwMC0weGU4MjJm ZmZmIGF0IGRldmljZSAyMC4wIG9uIHBjaTAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4g a2VybmVsOiB4aGNpMDogMzIgYnl0ZXMgY29udGV4dCBzaXplLCA2NC1iaXQgRE1BCk5vdiAyOSAx MTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogeGhjaTA6IHhFQ1AgY2FwYWJpbGl0aWVzIDxQ Uk9UTyxQUk9UTyxWRU5EKGMwKSxMRUdBQ1ksVkVORChjNiksVkVORChjNyksVkVORChjMiksREVC VUcsVkVORChjMyksVkVORChjNCksVkVORChjNSk+Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJt YW5uIGtlcm5lbDogdXNidXMwIG9uIHhoY2kwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5u IGtlcm5lbDogdXNidXMwOiA1LjBHYnBzIFN1cGVyIFNwZWVkIFVTQiB2My4wCk5vdiAyOSAxMToz NjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogcGNodGhlcm0wOiA8U2t5bGFrZSBQQ0ggVGhlcm1h bCBTdWJzeXN0ZW0+IG1lbSAweGU4MjUxMDAwLTB4ZTgyNTFmZmYgYXQgZGV2aWNlIDIwLjIgb24g cGNpMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHBjaTA6IDxzaW1wbGUg Y29tbXM+IGF0IGRldmljZSAyMi4wIChubyBkcml2ZXIgYXR0YWNoZWQpCk5vdiAyOSAxMTozNjow MCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMjguMCBvbiBwY2kwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog cGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1h bm4ga2VybmVsOiBwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC42IG9u IHBjaTAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBwY2kyOiA8QUNQSSBQ Q0kgYnVzPiBvbiBwY2liMgpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHBj aTI6IDxuZXR3b3JrPiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCk5vdiAyOSAx MTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtl cm5lbDogcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKTm92IDI5IDExOjM2OjAwIDwwLjI+ IGhlcm1hbm4ga2VybmVsOiBwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAy OS4yIG9uIHBjaTAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBwY2k0OiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJu ZWw6IG52bWUwOiA8R2VuZXJpYyBOVk1lIERldmljZT4gbWVtIDB4ZTgwMDAwMDAtMHhlODAwM2Zm ZiBhdCBkZXZpY2UgMC4wIG9uIHBjaTQKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2Vy bmVsOiBpc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCk5vdiAy OSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaXNhMDogPElTQSBidXM+IG9uIGlzYWIw Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogcGNpMDogPG1lbW9yeT4gYXQg ZGV2aWNlIDMxLjIgKG5vIGRyaXZlciBhdHRhY2hlZCkKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhl cm1hbm4ga2VybmVsOiBoZGFjMDogPEludGVsIEthYnkgTGFrZS1MUCBIREEgQ29udHJvbGxlcj4g bWVtIDB4ZTgyNDgwMDAtMHhlODI0YmZmZiwweGU4MjMwMDAwLTB4ZTgyM2ZmZmYgYXQgZGV2aWNl IDMxLjMgb24gcGNpMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGljaHNt YjA6IDxJbnRlbCBTdW5yaXNlIFBvaW50LUxQIFNNQnVzIGNvbnRyb2xsZXI+IHBvcnQgMHhlZmEw LTB4ZWZiZiBtZW0gMHhlODI1MzAwMC0weGU4MjUzMGZmIGF0IGRldmljZSAzMS40IG9uIHBjaTAK Tm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBlbTA6IDxJbnRlbChSKSBJMjE5 LVYgU1BUKDQpPiBtZW0gMHhlODIwMDAwMC0weGU4MjFmZmZmIGF0IGRldmljZSAzMS42IG9uIHBj aTAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBlbTA6IEVFUFJPTSBWMC4x LTMKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBlbTA6IFVzaW5nIDEwMjQg VFggZGVzY3JpcHRvcnMgYW5kIDEwMjQgUlggZGVzY3JpcHRvcnMKTm92IDI5IDExOjM2OjAwIDww LjI+IGhlcm1hbm4ga2VybmVsOiBlbTA6IFVzaW5nIGFuIE1TSSBpbnRlcnJ1cHQKTm92IDI5IDEx OjM2OjAwIDwwLjY+IGhlcm1hbm4ga2VybmVsOiBlbTA6IEV0aGVybmV0IGFkZHJlc3M6ICBNQUNB RERSRVNTCk5vdiAyOSAxMTozNjowMCA8MC42PiBoZXJtYW5uIGtlcm5lbDogZW0wOiBuZXRtYXAg cXVldWVzL3Nsb3RzOiBUWCAxLzEwMjQsIFJYIDEvMTAyNApOb3YgMjkgMTE6MzY6MDAgPDAuMj4g aGVybWFubiBrZXJuZWw6IGFjcGlfYnV0dG9uMDogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKTm92 IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBhY3BpX2xpZDA6IDxDb250cm9sIE1l dGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBr ZXJuZWw6IGFjcGlfdHowOiA8VGhlcm1hbCBab25lPiBvbiBhY3BpMApOb3YgMjkgMTE6MzY6MDAg PDAuMj4gaGVybWFubiBrZXJuZWw6IGF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0 Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBo ZXJtYW5uIGtlcm5lbDogYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKTm92 IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBrYmQwIGF0IGF0a2JkMApOb3YgMjkg MTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KTm92 IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBwc20wOiA8UFMvMiBNb3VzZT4gaXJx IDEyIG9uIGF0a2JkYzAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBwc20w OiBbR0lBTlQtTE9DS0VEXQpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IFdB Uk5JTkc6IERldmljZSAicHNtIiBpcyBHaWFudCBsb2NrZWQgYW5kIG1heSBiZSBkZWxldGVkIGJl Zm9yZSBGcmVlQlNEIDE2LjAuCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog cHNtMDogbW9kZWwgU3luYXB0aWNzIFRvdWNocGFkLCBkZXZpY2UgSUQgMApOb3YgMjkgMTE6MzY6 MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGFjcGlfYWNhZDA6IDxBQyBBZGFwdGVyPiBvbiBhY3Bp MApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGJhdHRlcnkwOiA8QUNQSSBD b250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVy bWFubiBrZXJuZWw6IGJhdHRlcnkxOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBh Y3BpMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGNvcmV0ZW1wMDogPENQ VSBPbi1EaWUgVGhlcm1hbCBTZW5zb3JzPiBvbiBjcHUwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBo ZXJtYW5uIGtlcm5lbDogaHdwc3RhdGVfaW50ZWwwOiA8SW50ZWwgU3BlZWQgU2hpZnQ+IG9uIGNw dTAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBjcHVmcmVxMDogPENQVSBm cmVxdWVuY3kgY29udHJvbD4gb24gY3B1MApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBr ZXJuZWw6IGh3cHN0YXRlX2ludGVsMTogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHUxCk5vdiAy OSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogY3B1ZnJlcTE6IDxDUFUgZnJlcXVlbmN5 IGNvbnRyb2w+IG9uIGNwdTEKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBo d3BzdGF0ZV9pbnRlbDI6IDxJbnRlbCBTcGVlZCBTaGlmdD4gb24gY3B1MgpOb3YgMjkgMTE6MzY6 MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGNwdWZyZXEyOiA8Q1BVIGZyZXF1ZW5jeSBjb250cm9s PiBvbiBjcHUyCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaHdwc3RhdGVf aW50ZWwzOiA8SW50ZWwgU3BlZWQgU2hpZnQ+IG9uIGNwdTMKTm92IDI5IDExOjM2OjAwIDwwLjI+ IGhlcm1hbm4ga2VybmVsOiBjcHVmcmVxMzogPENQVSBmcmVxdWVuY3kgY29udHJvbD4gb24gY3B1 MwpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGh3cHN0YXRlX2ludGVsNDog PEludGVsIFNwZWVkIFNoaWZ0PiBvbiBjcHU0Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5u IGtlcm5lbDogY3B1ZnJlcTQ6IDxDUFUgZnJlcXVlbmN5IGNvbnRyb2w+IG9uIGNwdTQKTm92IDI5 IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBod3BzdGF0ZV9pbnRlbDU6IDxJbnRlbCBT cGVlZCBTaGlmdD4gb24gY3B1NQpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6 IGNwdWZyZXE1OiA8Q1BVIGZyZXF1ZW5jeSBjb250cm9sPiBvbiBjcHU1Ck5vdiAyOSAxMTozNjow MCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaHdwc3RhdGVfaW50ZWw2OiA8SW50ZWwgU3BlZWQgU2hp ZnQ+IG9uIGNwdTYKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBjcHVmcmVx NjogPENQVSBmcmVxdWVuY3kgY29udHJvbD4gb24gY3B1NgpOb3YgMjkgMTE6MzY6MDAgPDAuMj4g aGVybWFubiBrZXJuZWw6IGh3cHN0YXRlX2ludGVsNzogPEludGVsIFNwZWVkIFNoaWZ0PiBvbiBj cHU3Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogY3B1ZnJlcTc6IDxDUFUg ZnJlcXVlbmN5IGNvbnRyb2w+IG9uIGNwdTcKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4g a2VybmVsOiBUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMTk5MTk5ODQxMSBIeiBxdWFsaXR5 IDEwMDAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBUaW1lY291bnRlcnMg dGljayBldmVyeSAxLjAwMCBtc2VjCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5l bDogdWdlbjAuMTogPEludGVsIFhIQ0kgcm9vdCBIVUI+IGF0IHVzYnVzMApOb3YgMjkgMTE6MzY6 MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHVodWIwIG9uIHVzYnVzMApOb3YgMjkgMTE6MzY6MDAg PDAuMj4gaGVybWFubiBrZXJuZWw6IHVodWIwOiA8SW50ZWwgWEhDSSByb290IEhVQiwgY2xhc3Mg OS8wLCByZXYgMy4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAu Mj4gaGVybWFubiBrZXJuZWw6IFpGUyBmaWxlc3lzdGVtIHZlcnNpb246IDUKTm92IDI5IDExOjM2 OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBaRlMgc3RvcmFnZSBwb29sIHZlcnNpb246IGZlYXR1 cmVzIHN1cHBvcnQgKDUwMDApCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog aXBmdzIgKCtpcHY2KSBpbml0aWFsaXplZCwgZGl2ZXJ0IGVuYWJsZWQsIG5hdCBsb2FkYWJsZSwg ZGVmYXVsdCB0byBhY2NlcHQsIGxvZ2dpbmcgZGlzYWJsZWQKTm92IDI5IDExOjM2OjAwIDwwLjI+ IGhlcm1hbm4ga2VybmVsOiBsb2FkX2RuX3NjaGVkIGRuX3NjaGVkIEZJRk8gbG9hZGVkCk5vdiAy OSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogbG9hZF9kbl9zY2hlZCBkbl9zY2hlZCBG UV9DT0RFTCBsb2FkZWQKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBsb2Fk X2RuX3NjaGVkIGRuX3NjaGVkIEZRX1BJRSBsb2FkZWQKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhl cm1hbm4ga2VybmVsOiBsb2FkX2RuX3NjaGVkIGRuX3NjaGVkIFBSSU8gbG9hZGVkCk5vdiAyOSAx MTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogbG9hZF9kbl9zY2hlZCBkbl9zY2hlZCBRRlEg bG9hZGVkCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogbG9hZF9kbl9zY2hl ZCBkbl9zY2hlZCBSUiBsb2FkZWQKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVs OiBsb2FkX2RuX3NjaGVkIGRuX3NjaGVkIFdGMlErIGxvYWRlZApOb3YgMjkgMTE6MzY6MDAgPDAu Mj4gaGVybWFubiBrZXJuZWw6IGxvYWRfZG5fYXFtIGRuX2FxbSBDT0RFTCBsb2FkZWQKTm92IDI5 IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBsb2FkX2RuX2FxbSBkbl9hcW0gUElFIGxv YWRlZApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IG52bWUwOiBBbGxvY2F0 ZWQgNjRNQiBob3N0IG1lbW9yeSBidWZmZXIKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4g a2VybmVsOiBoZGFjYzA6IDxSZWFsdGVrIEFMQzI1NyBIREEgQ09ERUM+IGF0IGNhZCAwIG9uIGhk YWMwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaGRhYTA6IDxSZWFsdGVr IEFMQzI1NyBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQgbmlkIDEgb24gaGRhY2MwCk5vdiAyOSAx MTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogcGNtMDogPFJlYWx0ZWsgQUxDMjU3IChBbmFs b2cgMi4wK0hQLzIuMCk+IGF0IG5pZCAyMCwzMyBhbmQgMTggb24gaGRhYTAKTm92IDI5IDExOjM2 OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBwY20xOiA8UmVhbHRlayBBTEMyNTcgKFJpZ2h0IEFu YWxvZyBNaWMpPiBhdCBuaWQgMjUgb24gaGRhYTAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1h bm4ga2VybmVsOiBoZGFjYzE6IDxJbnRlbCBLYWJ5IExha2UgSERBIENPREVDPiBhdCBjYWQgMiBv biBoZGFjMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGhkYWExOiA8SW50 ZWwgS2FieSBMYWtlIEF1ZGlvIEZ1bmN0aW9uIEdyb3VwPiBhdCBuaWQgMSBvbiBoZGFjYzEKTm92 IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBwY20yOiA8SW50ZWwgS2FieSBMYWtl IChIRE1JL0RQIDhjaCk+IGF0IG5pZCAzIG9uIGhkYWExCk5vdiAyOSAxMTozNjowMCA8MC4yPiBo ZXJtYW5uIGtlcm5lbDogc21idXMwOiA8U3lzdGVtIE1hbmFnZW1lbnQgQnVzPiBvbiBpY2hzbWIw Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogc21iMDogPFNNQnVzIGdlbmVy aWMgSS9PPiBvbiBzbWJ1czAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBu ZGEwIGF0IG52bWUwIGJ1cyAwIHNjYnVzMSB0YXJnZXQgMCBsdW4gMQpOb3YgMjkgMTE6MzY6MDAg PDAuMj4gaGVybWFubiBrZXJuZWw6IG5kYTA6IDxTYW1zdW5nIFNTRCA5OTAgRVZPIDFUQiAwQjJR S1hKNyBTN0dDTlMwWDEyODUyMFo+Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5l bDogbmRhMDogU2VyaWFsIE51bWJlciBTN0dDTlMwWDEyODUyMFoKTm92IDI5IDExOjM2OjAwIDww LjI+IGhlcm1hbm4ga2VybmVsOiBuZGEwOiBudm1lIHZlcnNpb24gMi4wCk5vdiAyOSAxMTozNjow MCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogbmRhMDogOTUzODY5TUIgKDE5NTM1MjUxNjggNTEyIGJ5 dGUgc2VjdG9ycykKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBod3BtYzog U09GVC8xNi82NC8weDY3PElOVCxVU1IsU1lTLFJFQSxXUkk+IFRTQy8xLzY0LzB4MjA8UkVBPiBJ QVAvNC80OC8weDNmZjxJTlQsVVNSLFNZUyxFREcsVEhSLFJFQSxXUkksSU5WLFFVQSxQUkM+IElB Ri8zLzQ4LzB4Njc8SU5ULFVTUixTWVMsUkVBLFdSST4KTm92IDI5IDExOjM2OjAwIDwwLjI+IGhl cm1hbm4ga2VybmVsOiBUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHpmczp6cm9vdC9ST09UL2Rl ZmF1bHQgW10uLi4KTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiB1aHViMDog MTggcG9ydHMgd2l0aCAxOCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApOb3YgMjkgMTE6MzY6MDAg PDAuMj4gaGVybWFubiBrZXJuZWw6IFJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMApOb3Yg MjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHVnZW4wLjI6IDxMb2dpdGVjaCBXaXJl bGVzcyBSZWNlaXZlcj4gYXQgdXNidXMwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtl cm5lbDogdXNiaGlkMCBvbiB1aHViMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJu ZWw6IHVzYmhpZDA6IDxMb2dpdGVjaCBXaXJlbGVzcyBSZWNlaXZlciwgY2xhc3MgMC8wLCByZXYg MS4xMC8zLjAyLCBhZGRyIDE+IG9uIHVzYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFu biBrZXJuZWw6IGhpZGJ1czA6IDxISUQgYnVzPiBvbiB1c2JoaWQwCk5vdiAyOSAxMTozNjowMCA8 MC4yPiBoZXJtYW5uIGtlcm5lbDogdWdlbjAuMzogPEdlbmVyaWMgRU1WIFNtYXJ0Y2FyZCBSZWFk ZXI+IGF0IHVzYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IFJvb3Qg bW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBr ZXJuZWw6IHVnZW4wLjQ6IDxGSUJPQ09NIEw4MzAtRUItMDA+IGF0IHVzYnVzMApOb3YgMjkgMTE6 MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHVnZW4wLjU6IDx2ZW5kb3IgMHg4MDg3IHByb2R1 Y3QgMHgwYTJiPiBhdCB1c2J1czAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVs OiB1YnQwIG9uIHVodWIwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogdWJ0 MDogPHZlbmRvciAweDgwODcgcHJvZHVjdCAweDBhMmIsIGNsYXNzIDIyNC8xLCByZXYgMi4wMC8w LjEwLCBhZGRyIDQ+IG9uIHVzYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJu ZWw6IFJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4g aGVybWFubiBrZXJuZWw6IHVnZW4wLjY6IDxBenVyZXdhdmUgSW50ZWdyYXRlZCBDYW1lcmE+IGF0 IHVzYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHVnZW4wLjc6IDxH ZW5lcmljIFVTQjMuMC1DUlc+IGF0IHVzYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFu biBrZXJuZWw6IHVtYXNzMCBvbiB1aHViMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBr ZXJuZWw6IHVtYXNzMDogPEdlbmVyaWMgVVNCMy4wLUNSVywgY2xhc3MgMC8wLCByZXYgMy4wMC8y LjA0LCBhZGRyIDY+IG9uIHVzYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJu ZWw6IChwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IFJFUE9SVCBMVU5TLiBDREI6IGEwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDEwIDAwIDAwIApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFu biBrZXJuZWw6IChwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IENBTSBzdGF0dXM6IFNDU0kgU3Rh dHVzIEVycm9yCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogKHByb2JlMDp1 bWFzcy1zaW0wOjA6MDowKTogU0NTSSBzdGF0dXM6IENoZWNrIENvbmRpdGlvbgpOb3YgMjkgMTE6 MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IChwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IFND U0kgc2Vuc2U6IElMTEVHQUwgUkVRVUVTVCBhc2M6MjQsMCAoSW52YWxpZCBmaWVsZCBpbiBDREIp Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogKHByb2JlMDp1bWFzcy1zaW0w OjA6MDowKTogRXJyb3IgMjIsIFVucmV0cnlhYmxlIGVycm9yCk5vdiAyOSAxMTozNjowMCA8MC4y PiBoZXJtYW5uIGtlcm5lbDogZGEwIGF0IHVtYXNzLXNpbTAgYnVzIDAgc2NidXMyIHRhcmdldCAw IGx1biAwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogZGEwOiA8R2VuZXJp Yy0gU0QvTU1DIDEuMDA+IFJlbW92YWJsZSBEaXJlY3QgQWNjZXNzIFNQQy00IFNDU0kgZGV2aWNl Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogZGEwOiBTZXJpYWwgTnVtYmVy IDIwMTIwNTAxMDMwOTAwMDAwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog ZGEwOiA0MDAuMDAwTUIvcyB0cmFuc2ZlcnMKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4g a2VybmVsOiBkYTA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVB RFksIE1lZGl1bSBub3QgcHJlc2VudApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJu ZWw6IGRhMDogcXVpcmtzPTB4MjxOT182X0JZVEU+Ck5vdiAyOSAxMTozNjowMCA8MC42PiBoZXJt YW5uIGtlcm5lbDogcGlkIDExOCAoenBvb2wpIGlzIGF0dGVtcHRpbmcgdG8gdXNlIHVuc2FmZSBB SU8gcmVxdWVzdHMgLSBub3QgbG9nZ2luZyBhbnltb3JlCk5vdiAyOSAxMTozNjowMCA8MC4yPiBo ZXJtYW5uIGtlcm5lbDogdGFyZ2NkZXZkdG9yOiBkZXN0cm95aW5nIG5vbi1lbmFibGVkIHRhcmdl dApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBzeXNsb2dkOiBsYXN0IG1lc3NhZ2UgcmVw ZWF0ZWQgMyB0aW1lcwpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IENQVTog SW50ZWwoUikgQ29yZShUTSkgaTctODU1MFUgQ1BVIEAgMS44MEdIeiAoMTk5Mi4wMC1NSHogSzgt Y2xhc3MgQ1BVKQpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6ICAgT3JpZ2lu PSJHZW51aW5lSW50ZWwiICBJZD0weDgwNmVhICBGYW1pbHk9MHg2ICBNb2RlbD0weDhlICBTdGVw cGluZz0xMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6ICAgRmVhdHVyZXM9 MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1U UlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxT U0UyLFNTLEhUVCxUTSxQQkU+Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog ICBGZWF0dXJlczI9MHg3ZmZhZmJiZjxTU0UzLFBDTE1VTFFEUSxEVEVTNjQsTU9OLERTX0NQTCxW TVgsRVNULFRNMixTU1NFMyxTREJHLEZNQSxDWDE2LHhUUFIsUERDTSxQQ0lELFNTRTQuMSxTU0U0 LjIseDJBUElDLE1PVkJFLFBPUENOVCxUU0NETFQsQUVTTkksWFNBVkUsT1NYU0FWRSxBVlgsRjE2 QyxSRFJBTkQ+Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogICBBTUQgRmVh dHVyZXM9MHgyYzEwMDgwMDxTWVNDQUxMLE5YLFBhZ2UxR0IsUkRUU0NQLExNPgpOb3YgMjkgMTE6 MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6ICAgQU1EIEZlYXR1cmVzMj0weDEyMTxMQUhGLEFC TSxQcmVmZXRjaD4KTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiAgIFN0cnVj dHVyZWQgRXh0ZW5kZWQgRmVhdHVyZXM9MHgyOWM2N2FmPEZTR1NCQVNFLFRTQ0FESixTR1gsQk1J MSxBVlgyLFNNRVAsQk1JMixFUk1TLElOVlBDSUQsTkZQVVNHLE1QWCxSRFNFRUQsQURYLFNNQVAs Q0xGTFVTSE9QVCxQUk9DVFJBQ0U+Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5l bDogICBTdHJ1Y3R1cmVkIEV4dGVuZGVkIEZlYXR1cmVzMz0weGJjMDAyZTAwPE1DVU9QVCxNRF9D TEVBUixUU1hGQSxJQlBCLFNUSUJQLEwxREZMLEFSQ0hfQ0FQLFNTQkQ+Ck5vdiAyOSAxMTozNjow MCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogICBYU0FWRSBGZWF0dXJlcz0weGY8WFNBVkVPUFQsWFNB VkVDLFhJTlVTRSxYU0FWRVM+Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog ICBJQTMyX0FSQ0hfQ0FQUz0weGEwMDBjMDQ8UlNCQT4KTm92IDI5IDExOjM2OjAwIDwwLjI+IGhl cm1hbm4ga2VybmVsOiAgIFZULXg6IFBBVCxITFQsTVRGLFBBVVNFLEVQVCxVRyxWUElECk5vdiAy OSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogICBUU0M6IFAtc3RhdGUgaW52YXJpYW50 LCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzCk5vdiAyOSAxMTozNjowMCA8MC42PiBoZXJtYW5uIGtl cm5lbDogW2RybV0gR290IEludGVsIGdyYXBoaWNzIHN0b2xlbiBtZW1vcnkgYmFzZSAweDdiODAw MDAwLCBzaXplIDB4NDAwMDAwMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6 IGRybW4wOiA8ZHJtbj4gb24gdmdhcGNpMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBr ZXJuZWw6IHZnYXBjaTA6IGNoaWxkIGRybW4wIHJlcXVlc3RlZCBwY2lfZW5hYmxlX2lvCk5vdiAy OSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIHN5c2xvZ2Q6IGxhc3QgbWVzc2FnZSByZXBlYXRlZCAx IHRpbWVzCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaTkxNS9rYmxfZG1j X3ZlcjFfMDQuYmluOiBjb3VsZCBub3QgbG9hZCBiaW5hcnkgZmlybXdhcmUgL2Jvb3QvZmlybXdh cmUvaTkxNS9rYmxfZG1jX3ZlcjFfMDQuYmluIGVpdGhlcgpOb3YgMjkgMTE6MzY6MDAgPDAuMj4g aGVybWFubiBrZXJuZWw6IGtibF9kbWNfdmVyMV8wNC5iaW46IGNvdWxkIG5vdCBsb2FkIGJpbmFy eSBmaXJtd2FyZSAvYm9vdC9maXJtd2FyZS9rYmxfZG1jX3ZlcjFfMDQuYmluIGVpdGhlcgpOb3Yg MjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGk5MTVfa2JsX2RtY192ZXIxXzA0LmJp bjogY291bGQgbm90IGxvYWQgYmluYXJ5IGZpcm13YXJlIC9ib290L2Zpcm13YXJlL2k5MTVfa2Js X2RtY192ZXIxXzA0LmJpbiBlaXRoZXIKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2Vy bmVsOiBsa3BpX2lpYzA6IDxMaW51eEtQSSBJMkM+IG9uIGRybW4wCk5vdiAyOSAxMTozNjowMCA8 MC4yPiBoZXJtYW5uIGtlcm5lbDogaWljYnVzMDogPFBoaWxpcHMgSTJDIGJ1cz4gb24gbGtwaV9p aWMwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaWljMDogPEkyQyBnZW5l cmljIEkvTz4gb24gaWljYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6 IGlpY3NtYjA6IDxTTUJ1cyBvdmVyIEkyQyBicmlkZ2U+IG9uIGlpY2J1czAKTm92IDI5IDExOjM2 OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBzbWJ1czE6IDxTeXN0ZW0gTWFuYWdlbWVudCBCdXM+ IG9uIGlpY3NtYjAKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBzbWIxOiA8 U01CdXMgZ2VuZXJpYyBJL08+IG9uIHNtYnVzMQpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFu biBrZXJuZWw6IGxrcGlfaWljMTogPExpbnV4S1BJIEkyQz4gb24gZHJtbjAKTm92IDI5IDExOjM2 OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBpaWNidXMxOiA8UGhpbGlwcyBJMkMgYnVzPiBvbiBs a3BpX2lpYzEKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBpaWMxOiA8STJD IGdlbmVyaWMgSS9PPiBvbiBpaWNidXMxCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtl cm5lbDogaWljc21iMTogPFNNQnVzIG92ZXIgSTJDIGJyaWRnZT4gb24gaWljYnVzMQpOb3YgMjkg MTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHNtYnVzMjogPFN5c3RlbSBNYW5hZ2VtZW50 IEJ1cz4gb24gaWljc21iMQpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHNt YjI6IDxTTUJ1cyBnZW5lcmljIEkvTz4gb24gc21idXMyCk5vdiAyOSAxMTozNjowMCA8MC4yPiBo ZXJtYW5uIGtlcm5lbDogbGtwaV9paWMyOiA8TGludXhLUEkgSTJDPiBvbiBkcm1uMApOb3YgMjkg MTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGlpY2J1czI6IDxQaGlsaXBzIEkyQyBidXM+ IG9uIGxrcGlfaWljMgpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGlpYzI6 IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czIKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1h bm4ga2VybmVsOiBpaWNzbWIyOiA8U01CdXMgb3ZlciBJMkMgYnJpZGdlPiBvbiBpaWNidXMyCk5v diAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogc21idXMzOiA8U3lzdGVtIE1hbmFn ZW1lbnQgQnVzPiBvbiBpaWNzbWIyCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5l bDogc21iMzogPFNNQnVzIGdlbmVyaWMgSS9PPiBvbiBzbWJ1czMKTm92IDI5IDExOjM2OjAwIDww LjI+IGhlcm1hbm4ga2VybmVsOiBkcm1uMDogc3VjY2Vzc2Z1bGx5IGxvYWRlZCBmaXJtd2FyZSBp bWFnZSAnaTkxNS9rYmxfZG1jX3ZlcjFfMDQuYmluJwpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVy bWFubiBrZXJuZWw6IGRybW4wOiBbZHJtXSBGaW5pc2hlZCBsb2FkaW5nIERNQyBmaXJtd2FyZSBp OTE1L2tibF9kbWNfdmVyMV8wNC5iaW4gKHYxLjQpCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJt YW5uIGtlcm5lbDogc3lzY3RsX2FkZF9vaWQ6IGNhbid0IHJlLXVzZSBhIGxlYWYgKGh3LmRyaS5k ZWJ1ZykhCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogbGtwaV9paWMzOiA8 TGludXhLUEkgSTJDPiBvbiBkcm0xCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5l bDogaWljYnVzMzogPFBoaWxpcHMgSTJDIGJ1cz4gb24gbGtwaV9paWMzCk5vdiAyOSAxMTozNjow MCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaWljMzogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVz MwpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGlpY3NtYjM6IDxTTUJ1cyBv dmVyIEkyQyBicmlkZ2U+IG9uIGlpY2J1czMKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4g a2VybmVsOiBzbWJ1czQ6IDxTeXN0ZW0gTWFuYWdlbWVudCBCdXM+IG9uIGlpY3NtYjMKTm92IDI5 IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBzbWI0OiA8U01CdXMgZ2VuZXJpYyBJL08+ IG9uIHNtYnVzNApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGxrcGlfaWlj NDogPExpbnV4S1BJIEkyQz4gb24gZHJtMgpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBr ZXJuZWw6IGlpY2J1czQ6IDxQaGlsaXBzIEkyQyBidXM+IG9uIGxrcGlfaWljNApOb3YgMjkgMTE6 MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGlpYzQ6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlp Y2J1czQKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBpaWNzbWI0OiA8U01C dXMgb3ZlciBJMkMgYnJpZGdlPiBvbiBpaWNidXM0Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJt YW5uIGtlcm5lbDogc21idXM1OiA8U3lzdGVtIE1hbmFnZW1lbnQgQnVzPiBvbiBpaWNzbWI0Ck5v diAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogc21iNTogPFNNQnVzIGdlbmVyaWMg SS9PPiBvbiBzbWJ1czUKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBsa3Bp X2lpYzU6IDxMaW51eEtQSSBJMkM+IG9uIGRybTQKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1h bm4ga2VybmVsOiBpaWNidXM1OiA8UGhpbGlwcyBJMkMgYnVzPiBvbiBsa3BpX2lpYzUKTm92IDI5 IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBpaWM1OiA8STJDIGdlbmVyaWMgSS9PPiBv biBpaWNidXM1Ck5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaWljc21iNTog PFNNQnVzIG92ZXIgSTJDIGJyaWRnZT4gb24gaWljYnVzNQpOb3YgMjkgMTE6MzY6MDAgPDAuMj4g aGVybWFubiBrZXJuZWw6IHNtYnVzNjogPFN5c3RlbSBNYW5hZ2VtZW50IEJ1cz4gb24gaWljc21i NQpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHNtYjY6IDxTTUJ1cyBnZW5l cmljIEkvTz4gb24gc21idXM2Ck5vdiAyOSAxMTozNjowMCA8MC42PiBoZXJtYW5uIGtlcm5lbDog W2RybV0gSW5pdGlhbGl6ZWQgaTkxNSAxLjYuMCAyMDIwMTEwMyBmb3IgZHJtbjAgb24gbWlub3Ig MApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IFZUOiBSZXBsYWNpbmcgZHJp dmVyICJlZmlmYiIgd2l0aCBuZXcgImRybWZiIi4KTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1h bm4ga2VybmVsOiBzdGFydCBGQl9JTkZPOgpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBr ZXJuZWw6IGhlaWdodD0xMDgwIHdpZHRoPTE5MjAgZGVwdGg9MzIKTm92IDI5IDExOjM2OjAwIDww LjI+IGhlcm1hbm4ga2VybmVsOiBwYmFzZT0weGMwMDAwMDAwIHZiYXNlPTB4ZmZmZmY4MDBjMDAw MDAwMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IG5hbWU9ZHJtbjAgaWQ9 aTkxNWRybWZiIGZsYWdzPTB4MCBzdHJpZGU9NzY4MApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVy bWFubiBrZXJuZWw6IGVuZCBGQl9JTkZPCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtl cm5lbDogYWNwaV93bWkwOiA8QUNQSS1XTUkgbWFwcGluZz4gb24gYWNwaTAKTm92IDI5IDExOjM2 OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBhY3BpX3dtaTE6IDxBQ1BJLVdNSSBtYXBwaW5nPiBv biBhY3BpMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGFjcGlfd21pMTog RW1iZWRkZWQgTU9GIGZvdW5kCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog YWNwaV93bWkyOiA8QUNQSS1XTUkgbWFwcGluZz4gb24gYWNwaTAKTm92IDI5IDExOjM2OjAwIDww LjI+IGhlcm1hbm4ga2VybmVsOiBhY3BpX3dtaTI6IEVtYmVkZGVkIE1PRiBmb3VuZApOb3YgMjkg MTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGFjcGlfd21pMzogPEFDUEktV01JIG1hcHBp bmc+IG9uIGFjcGkwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogYWNwaV93 bWkzOiBFbWJlZGRlZCBNT0YgZm91bmQKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2Vy bmVsOiBpd2x3aWZpMDogPGl3bHdpZmk+IG1lbSAweGU4MTAwMDAwLTB4ZTgxMDFmZmYgYXQgZGV2 aWNlIDAuMCBvbiBwY2kyCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaXds d2lmaTA6IERldGVjdGVkIGNyZi1pZCAweGJhZGNhZmUsIGNudi1pZCAweDEwIHdmcG0gaWQgMHg4 MDAwMDAwMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGl3bHdpZmkwOiBQ Q0kgZGV2IDI0ZmQvMDAxMCwgcmV2PTB4MjMwLCByZmlkPTB4ZDU1NTU1ZDUKTm92IDI5IDExOjM2 OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBpd2x3aWZpMDogRGV0ZWN0ZWQgSW50ZWwoUikgRHVh bCBCYW5kIFdpcmVsZXNzLUFDIDgyNjUKTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2Vy bmVsOiBpd2x3aWZpMDogc3VjY2Vzc2Z1bGx5IGxvYWRlZCBmaXJtd2FyZSBpbWFnZSAnaXdsd2lm aS04MjY1LTM2LnVjb2RlJwpOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGl3 bHdpZmkwOiBsb2FkZWQgZmlybXdhcmUgdmVyc2lvbiAzNi5jYTdiOTAxZC4wIDgyNjUtMzYudWNv ZGUgb3BfbW9kZSBpd2xtdm0KTm92IDI5IDExOjM2OjAwIDwwLjI+IGhlcm1hbm4ga2VybmVsOiBp d2x3aWZpMDogYmFzZSBIVyBhZGRyZXNzOiBNQUNBRERSRVNTLCBPVFAgbWlub3IgdmVyc2lvbjog MHgwCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaG1zMDogPExvZ2l0ZWNo IFdpcmVsZXNzIFJlY2VpdmVyIE1vdXNlPiBvbiBoaWRidXMwCk5vdiAyOSAxMTozNjowMCA8MC4y PiBoZXJtYW5uIGtlcm5lbDogaG1zMDogNSBidXR0b25zIGFuZCBbWFlXXSBjb29yZGluYXRlcyBJ RD0xCk5vdiAyOSAxMTozNjowMCA8MC42PiBoZXJtYW5uIGtlcm5lbDogd2xhbjA6IEV0aGVybmV0 IGFkZHJlc3M6IE1BQ0FERFJFU1MKTm92IDI5IDExOjM2OjAwIDwwLjY+IGhlcm1hbm4ga2VybmVs OiBlbTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUApOb3YgMjkgMTE6MzY6MDAgPDAuNj4gaGVy bWFubiBrZXJuZWw6IGxvMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCk5vdiAyOSAxMTozNjow MCA8MC42PiBoZXJtYW5uIGtlcm5lbDogZW0wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgpO b3YgMjkgMTE6MzY6MDAgPDAuNj4gaGVybWFubiBrZXJuZWw6IGVtMDogbGluayBzdGF0ZSBjaGFu Z2VkIHRvIFVQCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaXdsd2lmaTA6 IGxrcGlfc3RhX3NjYW5fdG9fYXV0aDoyNDE5OiBsdmlmIDB4ZmZmZmZlMDExYTc5YjAwMCB2YXAg MHhmZmZmZmUwMTFhNzliMDEwIGl2X2JzcyAweGZmZmZmZTAwZGZkNGYwMDAgbHZpZl9ic3MgMCBs dmlmX2Jzcy0+bmkgMCBzeW5jaGVkIDAsIG5pIDB4ZmZmZmZlMDExN2Q2YTAwMCBsc3RhIDB4ZmZm ZmY4MDA1YmQ3NjAwMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IGl3bHdp ZmkwOiBsa3BpX2l2X25ld3N0YXRlOiBlcnJvciA5NSBkdXJpbmcgc3RhdGUgdHJhbnNpdGlvbiAy IChBVVRIKSAtPiAyIChBVVRIKQpOb3YgMjkgMTE6MzY6MDAgPDAuNj4gaGVybWFubiBrZXJuZWw6 IHdsYW4wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKTm92IDI5IDExOjM2OjAwIDwwLjY+IGhl cm1hbm4ga2VybmVsOiB3bGFuMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KTm92IDI5IDEx OjM2OjAwIDwwLjY+IGhlcm1hbm4ga2VybmVsOiB3bGFuMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRv IFVQCk5vdiAyOSAxMTozNjowMCA8MC42PiBoZXJtYW5uIGtlcm5lbDogd2xhbjA6IGxpbmsgc3Rh dGUgY2hhbmdlZCB0byBET1dOCk5vdiAyOSAxMTozNjowMCA8MC4yPiBoZXJtYW5uIGtlcm5lbDog dW1vZGVtMCBvbiB1aHViMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHVt b2RlbTA6IDxGSUJPQ09NIEw4MzAtRUItMDAsIGNsYXNzIDIzOS8yLCByZXYgMi4wMC8zLjMzLCBh ZGRyIDM+IG9uIHVzYnVzMApOb3YgMjkgMTE6MzY6MDAgPDAuMj4gaGVybWFubiBrZXJuZWw6IHVt b2RlbTA6IGRhdGEgaW50ZXJmYWNlIDMsIGhhcyBubyBDTSBvdmVyIGRhdGEsIGhhcyBicmVhawpO b3YgMjkgMTE6MzY6MDAgPDAuNj4gaGVybWFubiBrZXJuZWw6IHdsYW4wOiBsaW5rIHN0YXRlIGNo YW5nZWQgdG8gVVAKTm92IDI5IDExOjM2OjAwIDwwLjY+IGhlcm1hbm4ga2VybmVsOiB3bGFuMDog bGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KTm92IDI5IDExOjM2OjAwIDwwLjY+IGhlcm1hbm4g a2VybmVsOiB3bGFuMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCk5vdiAyOSAxMTozNjowMCA8 MC42PiBoZXJtYW5uIGtlcm5lbDogd2xhbjA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dOCk5v diAyOSAxMTozNjowMCA8MC42PiBoZXJtYW5uIGtlcm5lbDogd2xhbjA6IGxpbmsgc3RhdGUgY2hh bmdlZCB0byBVUApOb3YgMjkgMTE6MzY6MDAgPDAuNj4gaGVybWFubiBrZXJuZWw6IHdsYW4wOiBs aW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgpOb3YgMjkgMTE6MzY6MDAgPDEyLjU+IGhlcm1hbm4g bnRwZFs0MjQwXTogbnRwZCA0LjIuOHAxOC1hICgxKTogU3RhcnRpbmcKTm92IDI5IDExOjM2OjAw IDwxMi41PiBoZXJtYW5uIG50cGRbNDI0MF06IENvbW1hbmQgbGluZTogL3Vzci9zYmluL250cGQg LXAgL3Zhci9kYi9udHAvbnRwZC5waWQgLWMgL2V0Yy9udHAuY29uZiAtZiAvdmFyL2RiL250cC9u dHBkLmRyaWZ0Ck5vdiAyOSAxMTozNjowMCA8MTIuNT4gaGVybWFubiBudHBkWzQyNDBdOiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCk5vdiAyOSAx MTozNjowMCA8MTIuNT4gaGVybWFubiBudHBkWzQyNDBdOiBudHAtNCBpcyBtYWludGFpbmVkIGJ5 IE5ldHdvcmsgVGltZSBGb3VuZGF0aW9uLApOb3YgMjkgMTE6MzY6MDAgPDEyLjU+IGhlcm1hbm4g bnRwZFs0MjQwXTogSW5jLiAoTlRGKSwgYSBub24tcHJvZml0IDUwMShjKSgzKSBwdWJsaWMtYmVu ZWZpdApOb3YgMjkgMTE6MzY6MDAgPDEyLjU+IGhlcm1hbm4gbnRwZFs0MjQwXTogY29ycG9yYXRp b24uICBTdXBwb3J0IGFuZCB0cmFpbmluZyBmb3IgbnRwLTQgYXJlCk5vdiAyOSAxMTozNjowMCA8 MTIuNT4gaGVybWFubiBudHBkWzQyNDBdOiBhdmFpbGFibGUgYXQgaHR0cHM6Ly93d3cubnd0aW1l Lm9yZy9zdXBwb3J0Ck5vdiAyOSAxMTozNjowMCA8MTIuNT4gaGVybWFubiBudHBkWzQyNDBdOiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCk5vdiAy OSAxMTozNjowMCA8MTIuNT4gaGVybWFubiBudHBkWzQyNTNdOiBsZWFwc2Vjb25kIGZpbGUgKCcv dmFyL2RiL250cGQubGVhcC1zZWNvbmRzLmxpc3QnKTogZ29vZCBoYXNoIHNpZ25hdHVyZQpOb3Yg MjkgMTE6MzY6MDAgPDEyLjU+IGhlcm1hbm4gbnRwZFs0MjUzXTogbGVhcHNlY29uZCBmaWxlICgn L3Zhci9kYi9udHBkLmxlYXAtc2Vjb25kcy5saXN0Jyk6IGxvYWRlZCwgZXhwaXJlPTIwMjUtMDYt MjhUMDA6MDA6MDBaIGxhc3Q9MjAxNy0wMS0wMVQwMDowMDowMFogb2ZzPTM3Ck5vdiAyOSAxMToz NjowMCA8MTIuMz4gaGVybWFubiBudHBkWzQyNTNdOiBsZWFwc2Vjb25kIGZpbGUgKCcvdmFyL2Ri L250cGQubGVhcC1zZWNvbmRzLmxpc3QnKTogZXhwaXJlZCAxNTUgZGF5cyBhZ28KTm92IDI5IDEx OjM2OjAyIDwzLjU+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IENUUkwtRVZF TlQtU1NJRC1SRUVOQUJMRUQgaWQ9MCBzc2lkPSJBUC1XaUZpIgpOb3YgMjkgMTE6MzY6MDIgPDMu NT4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogQWRkZWQgQlNTSUQgQlNTSURf TUFDIGludG8gaWdub3JlIGxpc3QsIGlnbm9yaW5nIGZvciAxMCBzZWNvbmRzCk5vdiAyOSAxMToz NjowMiA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBUcnlpbmcgdG8g YXNzb2NpYXRlIHdpdGggQlNTSURfTUFDIChTU0lEPSdBUC1XaUZpJyBmcmVxPTI0MzcgTUh6KQpO b3YgMjkgMTE6MzY6MDIgPDMuMz4gaGVybWFubiBkaGNwNmNbMzQzM106IHRyYW5zbWl0IGZhaWxl ZDogQ2FuJ3QgYXNzaWduIHJlcXVlc3RlZCBhZGRyZXNzCk5vdiAyOSAxMTozNjowMyA8MC4yPiBo ZXJtYW5uIGtlcm5lbDogaXdsd2lmaTA6IE5vdCBhc3NvY2lhdGVkIGFuZCB0aGUgdGltZSBldmVu dCBpcyBvdmVyIGFscmVhZHkuLi4KTm92IDI5IDExOjM2OjAzIDwwLjI+IGhlcm1hbm4ga2VybmVs OiBpd2x3aWZpMDogbGludXhrcGlfaWVlZTgwMjExX2Nvbm5lY3Rpb25fbG9zczogdmlmIDB4ZmZm ZmZlMDExYTc5YmYwMCB2YXAgMHhmZmZmZmUwMTFhNzliMDEwIHN0YXRlIEFTU09DIChzeW5jaGVk IDEsIGFzc29jIDAgYmVhY29ucyAwIGR0aW1fcGVyaW9kIDApCk5vdiAyOSAxMTozNjowNSA8MC4y PiBoZXJtYW5uIGtlcm5lbDogaXdsd2lmaTA6IGZhaWwgdG8gZmx1c2ggYWxsIHR4IGZpZm8gcXVl dWVzIFEgNQpOb3YgMjkgMTE6MzY6MDUgPDAuMj4gaGVybWFubiBrZXJuZWw6IGl3bHdpZmkwOiBR dWV1ZSA1IGlzIGFjdGl2ZSBvbiBmaWZvIDMgYW5kIHN0dWNrIGZvciAxMDAwMCBtcy4gU1cgWzIs IDNdIEhXIFsyLCAzXSBGSCBUUkI9MHgwODAzMDUwMDIKTm92IDI5IDExOjM2OjEyIDwzLjU+IGhl cm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IEF1dGhlbnRpY2F0aW9uIHdpdGggQlNT SURfTUFDIHRpbWVkIG91dC4KTm92IDI5IDExOjM2OjEyIDwzLjU+IGhlcm1hbm4gd3BhX3N1cHBs aWNhbnRbNjY1XTogd2xhbjA6IEJTU0lEIEJTU0lEX01BQyBpZ25vcmUgbGlzdCBjb3VudCBpbmNy ZW1lbnRlZCB0byAyLCBpZ25vcmluZyBmb3IgMTAgc2Vjb25kcwpOb3YgMjkgMTE6MzY6MTIgPDMu NT4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogQ1RSTC1FVkVOVC1ESVNDT05O RUNURUQgYnNzaWQ9QlNTSURfTUFDIHJlYXNvbj0zIGxvY2FsbHlfZ2VuZXJhdGVkPTEKTm92IDI5 IDExOjM2OjEyIDwzLjU+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IEJTU0lE IEJTU0lEX01BQyBpZ25vcmUgbGlzdCBjb3VudCBpbmNyZW1lbnRlZCB0byAzLCBpZ25vcmluZyBm b3IgNjAgc2Vjb25kcwpOb3YgMjkgMTE6MzY6MTIgPDMuNT4gaGVybWFubiB3cGFfc3VwcGxpY2Fu dFs2NjVdOiB3bGFuMDogQ1RSTC1FVkVOVC1TU0lELVRFTVAtRElTQUJMRUQgaWQ9MCBzc2lkPSJB UC1XaUZpIiBhdXRoX2ZhaWx1cmVzPTMgZHVyYXRpb249MzAgcmVhc29uPUNPTk5fRkFJTEVECk5v diAyOSAxMTozNjoxMiA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBD VFJMLUVWRU5ULURTQ1AtUE9MSUNZIGNsZWFyX2FsbApOb3YgMjkgMTE6MzY6MTIgPDMuNT4gaGVy bWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogVHJ5aW5nIHRvIGFzc29jaWF0ZSB3aXRo IEJTU0lEX01BQ19SRU1PVkVEIChTU0lEPSdUYW5uZW53YWxkJyBmcmVxPTI0MzcgTUh6KQpOb3Yg MjkgMTE6MzY6MTIgPDMuNT4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogQXNz b2NpYXRlZCB3aXRoIEJTU0lEX01BQ19SRU1PVkVECk5vdiAyOSAxMTozNjoxMiA8My4zPiBoZXJt YW5uIHdwYV9zdXBwbGljYW50WzY2NV06IGlvY3RsW1NJT0NTODAyMTEsIG9wPTE5LCB2YWw9MCwg YXJnX2xlbj02NF06IEludmFsaWQgYXJndW1lbnQKTm92IDI5IDExOjM2OjEyIDwzLjQ+IGhlcm1h bm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IFdQQTogRmFpbGVkIHRvIGNvbmZpZ3VyZSBJ R1RLIHRvIHRoZSBkcml2ZXIKTm92IDI5IDExOjM2OjEyIDwzLjU+IGhlcm1hbm4gd3BhX3N1cHBs aWNhbnRbNjY1XTogd2xhbjA6IFJTTjogRmFpbGVkIHRvIGNvbmZpZ3VyZSBJR1RLCk5vdiAyOSAx MTozNjoxMiA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBDVFJMLUVW RU5ULURJU0NPTk5FQ1RFRCBic3NpZD1CU1NJRF9NQUNfUkVNT1ZFRCByZWFzb249MSBsb2NhbGx5 X2dlbmVyYXRlZD0xCk5vdiAyOSAxMTozNjoxMiA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50 WzY2NV06IHdsYW4wOiBBZGRlZCBCU1NJRCBCU1NJRF9NQUNfUkVNT1ZFRCBpbnRvIGlnbm9yZSBs aXN0LCBpZ25vcmluZyBmb3IgMTAgc2Vjb25kcwpOb3YgMjkgMTE6MzY6MTIgPDMuNT4gaGVybWFu biB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogQ1RSTC1FVkVOVC1TU0lELVRFTVAtRElTQUJM RUQgaWQ9MSBzc2lkPSJUYW5uZW53YWxkIiBhdXRoX2ZhaWx1cmVzPTIgZHVyYXRpb249MjAgcmVh c29uPUNPTk5fRkFJTEVECk5vdiAyOSAxMTozNjoxMiA8My4zPiBoZXJtYW5uIHdwYV9zdXBwbGlj YW50WzY2NV06IGlvY3RsW1NJT0NTODAyMTEsIG9wPTIwLCB2YWw9MCwgYXJnX2xlbj03XTogSW52 YWxpZCBhcmd1bWVudApOb3YgMjkgMTE6MzY6MTIgPDMuNT4gaGVybWFubiB3cGFfc3VwcGxpY2Fu dFs2NjVdOiB3bGFuMDogQ1RSTC1FVkVOVC1EU0NQLVBPTElDWSBjbGVhcl9hbGwKTm92IDI5IDEx OjM2OjEyIDwwLjY+IGhlcm1hbm4ga2VybmVsOiB3bGFuMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRv IFVQCk5vdiAyOSAxMTozNjoxMiA8MC42PiBoZXJtYW5uIGtlcm5lbDogd2xhbjA6IGxpbmsgc3Rh dGUgY2hhbmdlZCB0byBET1dOCk5vdiAyOSAxMTozNjoxMyA8My41PiBoZXJtYW5uIHdwYV9zdXBw bGljYW50WzY2NV06IHdsYW4wOiBSZW1vdmVkIEJTU0lEIEJTU0lEX01BQ19SRU1PVkVEIGZyb20g aWdub3JlIGxpc3QgKGNsZWFyKQpOb3YgMjkgMTE6MzY6MTMgPDMuNT4gaGVybWFubiB3cGFfc3Vw cGxpY2FudFs2NjVdOiB3bGFuMDogUmVtb3ZlZCBCU1NJRCBCU1NJRF9NQUMgZnJvbSBpZ25vcmUg bGlzdCAoY2xlYXIpCk5vdiAyOSAxMTozNjoyOSA8My40PiBoZXJtYW5uIC91c3IvbG9jYWwvYmlu L3dtYWtlcls0NTIwXTogKGdldF9pY29uX2ZpbGVuYW1lKHdkZWZhdWx0cy5jOjQwNCkpOiB3YXJu aW5nOiBpY29uICJWQm94LnBuZyIgZG9lc24ndCBleGlzdCwgY2hlY2sgeW91ciBjb25maWcgZmls ZXMKTm92IDI5IDExOjM2OjI5IDwzLjQ+IGhlcm1hbm4gL3Vzci9sb2NhbC9iaW4vd21ha2VyWzQ1 MjBdOiAoZ2V0X2ljb25fZmlsZW5hbWUod2RlZmF1bHRzLmM6NDA0KSk6IHdhcm5pbmc6IGljb24g Im1wbGF5ZXIucG5nIiBkb2Vzbid0IGV4aXN0LCBjaGVjayB5b3VyIGNvbmZpZyBmaWxlcwpOb3Yg MjkgMTE6MzY6MzQgPDMuNT4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogQ1RS TC1FVkVOVC1TU0lELVJFRU5BQkxFRCBpZD0xIHNzaWQ9IlRhbm5lbndhbGQiCk5vdiAyOSAxMToz NjozNCA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBBZGRlZCBCU1NJ RCBCU1NJRF9NQUNfUkVNT1ZFRCBpbnRvIGlnbm9yZSBsaXN0LCBpZ25vcmluZyBmb3IgMTAgc2Vj b25kcwpOb3YgMjkgMTE6MzY6MzQgPDMuNT4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3 bGFuMDogVHJ5aW5nIHRvIGFzc29jaWF0ZSB3aXRoIEJTU0lEX01BQ19SRU1PVkVEIChTU0lEPSdU YW5uZW53YWxkJyBmcmVxPTI0MzcgTUh6KQpOb3YgMjkgMTE6MzY6MzQgPDMuMz4gaGVybWFubiBk aGNwNmNbMzQzM106IHRyYW5zbWl0IGZhaWxlZDogQ2FuJ3QgYXNzaWduIHJlcXVlc3RlZCBhZGRy ZXNzCk5vdiAyOSAxMTozNjozNSA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaXdsd2lmaTA6IE5vdCBh c3NvY2lhdGVkIGFuZCB0aGUgdGltZSBldmVudCBpcyBvdmVyIGFscmVhZHkuLi4KTm92IDI5IDEx OjM2OjM1IDwwLjI+IGhlcm1hbm4ga2VybmVsOiBpd2x3aWZpMDogbGludXhrcGlfaWVlZTgwMjEx X2Nvbm5lY3Rpb25fbG9zczogdmlmIDB4ZmZmZmZlMDExYTc5YmYwMCB2YXAgMHhmZmZmZmUwMTFh NzliMDEwIHN0YXRlIEFTU09DIChzeW5jaGVkIDEsIGFzc29jIDAgYmVhY29ucyAwIGR0aW1fcGVy aW9kIDApCk5vdiAyOSAxMTozNjozNyA8MC4yPiBoZXJtYW5uIGtlcm5lbDogaXdsd2lmaTA6IGZh aWwgdG8gZmx1c2ggYWxsIHR4IGZpZm8gcXVldWVzIFEgNQpOb3YgMjkgMTE6MzY6MzcgPDAuMj4g aGVybWFubiBrZXJuZWw6IGl3bHdpZmkwOiBRdWV1ZSA1IGlzIGFjdGl2ZSBvbiBmaWZvIDMgYW5k IHN0dWNrIGZvciAxMDAwMCBtcy4gU1cgWzIsIDNdIEhXIFsyLCAzXSBGSCBUUkI9MHgwODAzMDUw MDIKTm92IDI5IDExOjM2OjQ0IDwzLjU+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xh bjA6IEF1dGhlbnRpY2F0aW9uIHdpdGggQlNTSURfTUFDX1JFTU9WRUQgdGltZWQgb3V0LgpOb3Yg MjkgMTE6MzY6NDQgPDMuNT4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogQlNT SUQgQlNTSURfTUFDX1JFTU9WRUQgaWdub3JlIGxpc3QgY291bnQgaW5jcmVtZW50ZWQgdG8gMiwg aWdub3JpbmcgZm9yIDEwIHNlY29uZHMKTm92IDI5IDExOjM2OjQ0IDwzLjU+IGhlcm1hbm4gd3Bh X3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IENUUkwtRVZFTlQtRElTQ09OTkVDVEVEIGJzc2lkPUJT U0lEX01BQ19SRU1PVkVEIHJlYXNvbj0zIGxvY2FsbHlfZ2VuZXJhdGVkPTEKTm92IDI5IDExOjM2 OjQ0IDwzLjU+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IEJTU0lEIEJTU0lE X01BQ19SRU1PVkVEIGlnbm9yZSBsaXN0IGNvdW50IGluY3JlbWVudGVkIHRvIDMsIGlnbm9yaW5n IGZvciA2MCBzZWNvbmRzCk5vdiAyOSAxMTozNjo0NCA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGlj YW50WzY2NV06IHdsYW4wOiBDVFJMLUVWRU5ULVNTSUQtVEVNUC1ESVNBQkxFRCBpZD0xIHNzaWQ9 IlRhbm5lbndhbGQiIGF1dGhfZmFpbHVyZXM9MyBkdXJhdGlvbj0zMCByZWFzb249Q09OTl9GQUlM RUQKTm92IDI5IDExOjM2OjQ0IDwzLjU+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xh bjA6IENUUkwtRVZFTlQtRFNDUC1QT0xJQ1kgY2xlYXJfYWxsCk5vdiAyOSAxMTozNjo0NCA8My41 PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBDVFJMLUVWRU5ULVNTSUQtUkVF TkFCTEVEIGlkPTAgc3NpZD0iQVAtV2lGaSIKTm92IDI5IDExOjM2OjQ0IDwzLjU+IGhlcm1hbm4g d3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IEFkZGVkIEJTU0lEIEJTU0lEX01BQyBpbnRvIGln bm9yZSBsaXN0LCBpZ25vcmluZyBmb3IgMTAgc2Vjb25kcwpOb3YgMjkgMTE6MzY6NDQgPDMuNT4g aGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogVHJ5aW5nIHRvIGFzc29jaWF0ZSB3 aXRoIEJTU0lEX01BQyAoU1NJRD0nQVAtV2lGaScgZnJlcT0yNDM3IE1IeikKTm92IDI5IDExOjM2 OjQ1IDwwLjI+IGhlcm1hbm4ga2VybmVsOiBpd2x3aWZpMDogTm90IGFzc29jaWF0ZWQgYW5kIHRo ZSB0aW1lIGV2ZW50IGlzIG92ZXIgYWxyZWFkeS4uLgpOb3YgMjkgMTE6MzY6NDUgPDAuMj4gaGVy bWFubiBrZXJuZWw6IGl3bHdpZmkwOiBsaW51eGtwaV9pZWVlODAyMTFfY29ubmVjdGlvbl9sb3Nz OiB2aWYgMHhmZmZmZmUwMTFhNzliZjAwIHZhcCAweGZmZmZmZTAxMWE3OWIwMTAgc3RhdGUgQVVU SCAoc3luY2hlZCAxLCBhc3NvYyAwIGJlYWNvbnMgMCBkdGltX3BlcmlvZCAwKQpOb3YgMjkgMTE6 MzY6NTQgPDMuNT4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogQXV0aGVudGlj YXRpb24gd2l0aCBCU1NJRF9NQUMgdGltZWQgb3V0LgpOb3YgMjkgMTE6MzY6NTQgPDMuNT4gaGVy bWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogQlNTSUQgQlNTSURfTUFDIGlnbm9yZSBs aXN0IGNvdW50IGluY3JlbWVudGVkIHRvIDIsIGlnbm9yaW5nIGZvciAxMCBzZWNvbmRzCk5vdiAy OSAxMTozNjo1NCA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBDVFJM LUVWRU5ULURJU0NPTk5FQ1RFRCBic3NpZD1CU1NJRF9NQUMgcmVhc29uPTMgbG9jYWxseV9nZW5l cmF0ZWQ9MQpOb3YgMjkgMTE6MzY6NTQgPDMuNT4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVd OiB3bGFuMDogQlNTSUQgQlNTSURfTUFDIGlnbm9yZSBsaXN0IGNvdW50IGluY3JlbWVudGVkIHRv IDMsIGlnbm9yaW5nIGZvciA2MCBzZWNvbmRzCk5vdiAyOSAxMTozNjo1NCA8My41PiBoZXJtYW5u IHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBDVFJMLUVWRU5ULVNTSUQtVEVNUC1ESVNBQkxF RCBpZD0wIHNzaWQ9IkFQLVdpRmkiIGF1dGhfZmFpbHVyZXM9NCBkdXJhdGlvbj02MCByZWFzb249 Q09OTl9GQUlMRUQKTm92IDI5IDExOjM2OjU0IDwzLjU+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRb NjY1XTogd2xhbjA6IENUUkwtRVZFTlQtRFNDUC1QT0xJQ1kgY2xlYXJfYWxsCk5vdiAyOSAxMToz Njo1NSA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBSZW1vdmVkIEJT U0lEIEJTU0lEX01BQyBmcm9tIGlnbm9yZSBsaXN0IChjbGVhcikKTm92IDI5IDExOjM2OjU1IDwz LjU+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IFJlbW92ZWQgQlNTSUQgQlNT SURfTUFDX1JFTU9WRUQgZnJvbSBpZ25vcmUgbGlzdCAoY2xlYXIpCk5vdiAyOSAxMTozNzoxOCA8 My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBDVFJMLUVWRU5ULVNTSUQt UkVFTkFCTEVEIGlkPTEgc3NpZD0iVGFubmVud2FsZCIKTm92IDI5IDExOjM3OjE4IDwzLjU+IGhl cm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IEFkZGVkIEJTU0lEIEJTU0lEX01BQ19S RU1PVkVEIGludG8gaWdub3JlIGxpc3QsIGlnbm9yaW5nIGZvciAxMCBzZWNvbmRzCk5vdiAyOSAx MTozNzoxOCA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBUcnlpbmcg dG8gYXNzb2NpYXRlIHdpdGggQlNTSURfTUFDX1JFTU9WRUQgKFNTSUQ9J1Rhbm5lbndhbGQnIGZy ZXE9MjQzNyBNSHopCk5vdiAyOSAxMTozNzoxOCA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50 WzY2NV06IHdsYW4wOiBBc3NvY2lhdGVkIHdpdGggQlNTSURfTUFDX1JFTU9WRUQKTm92IDI5IDEx OjM3OjE4IDwzLjM+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogaW9jdGxbU0lPQ1M4MDIx MSwgb3A9MTksIHZhbD0wLCBhcmdfbGVuPTY0XTogSW52YWxpZCBhcmd1bWVudApOb3YgMjkgMTE6 Mzc6MTggPDMuND4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogV1BBOiBGYWls ZWQgdG8gY29uZmlndXJlIElHVEsgdG8gdGhlIGRyaXZlcgpOb3YgMjkgMTE6Mzc6MTggPDMuNT4g aGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogUlNOOiBGYWlsZWQgdG8gY29uZmln dXJlIElHVEsKTm92IDI5IDExOjM3OjE4IDwzLjU+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1 XTogd2xhbjA6IENUUkwtRVZFTlQtRElTQ09OTkVDVEVEIGJzc2lkPUJTU0lEX01BQ19SRU1PVkVE IHJlYXNvbj0xIGxvY2FsbHlfZ2VuZXJhdGVkPTEKTm92IDI5IDExOjM3OjE4IDwzLjU+IGhlcm1h bm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IEJTU0lEIEJTU0lEX01BQ19SRU1PVkVEIGln bm9yZSBsaXN0IGNvdW50IGluY3JlbWVudGVkIHRvIDIsIGlnbm9yaW5nIGZvciAxMCBzZWNvbmRz Ck5vdiAyOSAxMTozNzoxOCA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4w OiBDVFJMLUVWRU5ULVNTSUQtVEVNUC1ESVNBQkxFRCBpZD0xIHNzaWQ9IlRhbm5lbndhbGQiIGF1 dGhfZmFpbHVyZXM9NCBkdXJhdGlvbj02MCByZWFzb249Q09OTl9GQUlMRUQKTm92IDI5IDExOjM3 OjE4IDwzLjM+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogaW9jdGxbU0lPQ1M4MDIxMSwg b3A9MjAsIHZhbD0wLCBhcmdfbGVuPTddOiBJbnZhbGlkIGFyZ3VtZW50Ck5vdiAyOSAxMTozNzox OCA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBDVFJMLUVWRU5ULURT Q1AtUE9MSUNZIGNsZWFyX2FsbApOb3YgMjkgMTE6Mzc6MTggPDAuNj4gaGVybWFubiBrZXJuZWw6 IHdsYW4wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKTm92IDI5IDExOjM3OjE4IDwwLjY+IGhl cm1hbm4ga2VybmVsOiB3bGFuMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KTm92IDI5IDEx OjM3OjE5IDwzLjU+IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IFJlbW92ZWQg QlNTSUQgQlNTSURfTUFDX1JFTU9WRUQgZnJvbSBpZ25vcmUgbGlzdCAoY2xlYXIpCk5vdiAyOSAx MTozNzozOSA8My4zPiBoZXJtYW5uIGRoY3A2Y1szNDMzXTogdHJhbnNtaXQgZmFpbGVkOiBDYW4n dCBhc3NpZ24gcmVxdWVzdGVkIGFkZHJlc3MKTm92IDI5IDExOjM3OjU2IDwzLjU+IGhlcm1hbm4g d3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IENUUkwtRVZFTlQtU1NJRC1SRUVOQUJMRUQgaWQ9 MCBzc2lkPSJBUC1XaUZpIgpOb3YgMjkgMTE6Mzc6NTYgPDMuNT4gaGVybWFubiB3cGFfc3VwcGxp Y2FudFs2NjVdOiB3bGFuMDogQWRkZWQgQlNTSUQgQlNTSURfTUFDIGludG8gaWdub3JlIGxpc3Qs IGlnbm9yaW5nIGZvciAxMCBzZWNvbmRzCk5vdiAyOSAxMTozNzo1NiA8My41PiBoZXJtYW5uIHdw YV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBUcnlpbmcgdG8gYXNzb2NpYXRlIHdpdGggQlNTSURf TUFDIChTU0lEPSdBUC1XaUZpJyBmcmVxPTI0MzcgTUh6KQpOb3YgMjkgMTE6Mzc6NTYgPDMuNT4g aGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDogQXNzb2NpYXRlZCB3aXRoIEJTU0lE X01BQwpOb3YgMjkgMTE6Mzc6NTYgPDMuMz4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiBp b2N0bFtTSU9DUzgwMjExLCBvcD0xOSwgdmFsPTAsIGFyZ19sZW49NjRdOiBJbnZhbGlkIGFyZ3Vt ZW50Ck5vdiAyOSAxMTozNzo1NiA8My40PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHds YW4wOiBXUEE6IEZhaWxlZCB0byBjb25maWd1cmUgSUdUSyB0byB0aGUgZHJpdmVyCk5vdiAyOSAx MTozNzo1NiA8My41PiBoZXJtYW5uIHdwYV9zdXBwbGljYW50WzY2NV06IHdsYW4wOiBSU046IEZh aWxlZCB0byBjb25maWd1cmUgSUdUSwpOb3YgMjkgMTE6Mzc6NTYgPDMuNT4gaGVybWFubiB3cGFf c3VwcGxpY2FudFs2NjVdOiB3bGFuMDogQ1RSTC1FVkVOVC1ESVNDT05ORUNURUQgYnNzaWQ9QlNT SURfTUFDIHJlYXNvbj0xIGxvY2FsbHlfZ2VuZXJhdGVkPTEKTm92IDI5IDExOjM3OjU2IDwzLjU+ IGhlcm1hbm4gd3BhX3N1cHBsaWNhbnRbNjY1XTogd2xhbjA6IEJTU0lEIEJTU0lEX01BQyBpZ25v cmUgbGlzdCBjb3VudCBpbmNyZW1lbnRlZCB0byAyLCBpZ25vcmluZyBmb3IgMTAgc2Vjb25kcwpO b3YgMjkgMTE6Mzc6NTYgPDMuNT4gaGVybWFubiB3cGFfc3VwcGxpY2FudFs2NjVdOiB3bGFuMDog Q1RSTC1FVkVOVC1TU0lELVRFTVAtRElTQUJMRUQgaWQ9MCBzc2lkPSJBUC1XaUZpIiBhdXRoX2Zh aWx1cmVzPTUgZHVyYXRpb249NjAgcmVhc29uPUNPTk5fRkFJTEVECg== --MP_/W_I_34BVXS2S2tDXNX6AolW Content-Type: text/x-log Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=console_debug.log Nov 29 11:36:00 <14.6> hermann kernel: Nov 29 11:34:24 <1.2> hermann reboot[4766]: rebooted by ohartmann Nov 29 11:36:00 <14.6> hermann kernel: Nov 29 11:34:24 <5.3> hermann syslogd: exiting on signal 15 Nov 29 11:36:00 <14.6> hermann kernel: sysctl: oid 'net.inet.ip.fw.default_to_accept' is a read only tunable at line 98 Nov 29 11:36:00 <14.6> hermann kernel: sysctl: Tunable values are set in /boot/loader.conf Nov 29 11:36:00 <14.6> hermann kernel: Setting hostuuid: 363e74eb-c1e3-11e3-994c-28d244798732. Nov 29 11:36:00 <14.6> hermann kernel: Setting hostid: 0x3f4b201d. Nov 29 11:36:00 <14.6> hermann kernel: Starting file system checks: Nov 29 11:36:00 <14.6> hermann kernel: Mounting local filesystems:. Nov 29 11:36:00 <14.6> hermann kernel: cannot import 'zroot': pool already exists Nov 29 11:36:00 <14.6> hermann kernel: cachefile import failed, retrying Nov 29 11:36:00 <14.6> hermann kernel: cannot import '(null)': no such pool available Nov 29 11:36:00 <14.6> hermann kernel: Import of zpool cache /boot/zfs/zpool.cache failed, will retry after root mount hold release Nov 29 11:36:00 <14.6> hermann kernel: cannot import 'zroot': pool already exists Nov 29 11:36:00 <14.6> hermann kernel: cachefile import failed, retrying Nov 29 11:36:00 <14.6> hermann kernel: cannot import '(null)': no such pool available Nov 29 11:36:00 <14.6> hermann kernel: No SMB support in FreeBSD yet. Nov 29 11:36:00 <14.6> hermann kernel: cannot share 'zroot/vboxshare: operation not supported': SMB share creation failed Nov 29 11:36:00 <14.6> hermann kernel: Updating CPU Microcode... Nov 29 11:36:00 <14.6> hermann kernel: Done. Nov 29 11:36:00 <14.6> hermann kernel: mixer: pcm0:mixer:: no such device Nov 29 11:36:00 <14.6> hermann kernel: mixer: pcm1:mixer:: no such device Nov 29 11:36:00 <14.6> hermann kernel: ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/gcc11 /usr/local/lib/gcc12 /usr/local/lib/gcc13 /usr/local/lib/gcc14 /usr/local/lib/ipsec /usr/local/lib/mysql /usr/local/lib/perl5/5.42/mach/CORE /usr/local/lib/qt5 /usr/local/lib/qt6 /usr/local/lib/samba4 /usr/local/llvm15/lib /usr/local/llvm16/lib /usr/local/llvm18/lib /usr/local/llvm19/lib /usr/local/llvm19/lib/x86_64-portbld-freebsd15.0 /usr/local/llvm20/lib /usr/local/llvm20/lib/x86_64-portbld-freebsd15.0 /usr/local/llvm21/lib /usr/local/llvm21/lib/x86_64-portbld-freebsd15.0 /usr/local/openjdk11/lib/server /usr/local/openjdk8/lib/amd64 Nov 29 11:36:00 <14.6> hermann kernel: 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/gcc12 /usr/local/lib32/gcc13 /usr/local/lib32/gcc14 Nov 29 11:36:00 <14.6> hermann kernel: Setting hostname: hermann. Nov 29 11:36:00 <14.6> hermann kernel: Additional TCP/IP options: IPv6 Privacy Addresses. Nov 29 11:36:00 <14.6> hermann kernel: Setting up harvesting: PURE_RDSEED,RANDOMDEV,[CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED Nov 29 11:36:00 <14.6> hermann kernel: Feeding entropy: . Nov 29 11:36:00 <14.6> hermann kernel: Starting autounmountd. Nov 29 11:36:00 <14.6> hermann kernel: Loading kernel modules: linux linux64 i915kms if_ure Nov 29 11:36:00 <14.6> hermann kernel: Autoloading module: acpi_wmi Nov 29 11:36:00 <14.6> hermann kernel: Autoloading module: hms Nov 29 11:36:00 <14.6> hermann kernel: Autoloading module: if_iwlwifi Nov 29 11:36:00 <14.6> hermann kernel: wlandebug: sysctl-get(net.wlan.0.debug): No such file or directory Nov 29 11:36:00 <14.6> hermann kernel: Created wlan(4) interfaces: wlan0. Nov 29 11:36:00 <14.6> hermann kernel: Created clone interfaces: lagg0. Nov 29 11:36:00 <14.6> hermann kernel: Starting wpa_supplicant. Nov 29 11:36:00 <14.6> hermann kernel: Starting Network: lo0 em0 enc0 wlan0 lagg0. Nov 29 11:36:00 <14.6> hermann kernel: lo0: flags=1008049 metric 0 mtu 16384 Nov 29 11:36:00 <14.6> hermann kernel: options=680003 Nov 29 11:36:00 <14.6> hermann kernel: inet 127.0.0.1 netmask 0xff000000 Nov 29 11:36:00 <14.6> hermann kernel: inet6 ::1 prefixlen 128 Nov 29 11:36:00 <14.6> hermann kernel: inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 Nov 29 11:36:00 <14.6> hermann kernel: groups: lo Nov 29 11:36:00 <14.6> hermann kernel: nd6 options=21 Nov 29 11:36:00 <14.6> hermann kernel: em0: flags=1008843 metric 0 mtu 1500 Nov 29 11:36:00 <14.6> hermann kernel: options=4e524bb Nov 29 11:36:00 <14.6> hermann kernel: ether MAC Nov 29 11:36:00 <14.6> hermann kernel: inet6 fe80::LINKLOCAL%em0 prefixlen 64 scopeid 0x1 Nov 29 11:36:00 <14.6> hermann kernel: inet6 ULA prefixlen 64 autoconf pltime 604800 vltime 2592000 Nov 29 11:36:00 <14.6> hermann kernel: inet6 ULA_priv prefixlen 64 autoconf temporary pltime 86133 vltime 172800 Nov 29 11:36:00 <14.6> hermann kernel: inet6 IPV6 prefixlen 64 autoconf pltime 604800 vltime 2592000 Nov 29 11:36:00 <14.6> hermann kernel: inet6 IPV6_priv prefixlen 64 autoconf temporary pltime 86133 vltime 172800 Nov 29 11:36:00 <14.6> hermann kernel: media: Ethernet autoselect (1000baseT ) Nov 29 11:36:00 <14.6> hermann kernel: status: active Nov 29 11:36:00 <14.6> hermann kernel: nd6 options=23 Nov 29 11:36:00 <14.6> hermann kernel: enc0: flags=0 metric 0 mtu 1536 Nov 29 11:36:00 <14.6> hermann kernel: options=0 Nov 29 11:36:00 <14.6> hermann kernel: groups: enc Nov 29 11:36:00 <14.6> hermann kernel: nd6 options=29 Nov 29 11:36:00 <14.6> hermann kernel: wlan0: flags=8c43 metric 0 mtu 1500 Nov 29 11:36:00 <14.6> hermann kernel: options=0 Nov 29 11:36:00 <14.6> hermann kernel: ether MAC Nov 29 11:36:00 <14.6> hermann kernel: inet6 fe80::LINKLOCAL%wlan0 prefixlen 64 scopeid 0x4 Nov 29 11:36:00 <14.6> hermann kernel: groups: wlan Nov 29 11:36:00 <14.6> hermann kernel: ssid "" channel 1 (2412 MHz 11g) Nov 29 11:36:00 <14.6> hermann kernel: regdomain FCC country US authmode WPA1+WPA2/802.11i privacy ON Nov 29 11:36:00 <14.6> hermann kernel: deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS wme Nov 29 11:36:00 <14.6> hermann kernel: roaming MANUAL Nov 29 11:36:00 <14.6> hermann kernel: parent interface: iwlwifi0 Nov 29 11:36:00 <14.6> hermann kernel: media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) Nov 29 11:36:00 <14.6> hermann kernel: status: no carrier Nov 29 11:36:00 <14.6> hermann kernel: nd6 options=23 Nov 29 11:36:00 <14.6> hermann kernel: lagg0: flags=8802 metric 0 mtu 1500 Nov 29 11:36:00 <14.6> hermann kernel: options=800000 Nov 29 11:36:00 <14.6> hermann kernel: ether 00:00:00:00:00:00 Nov 29 11:36:00 <14.6> hermann kernel: laggproto failover lagghash l2,l3,l4 Nov 29 11:36:00 <14.6> hermann kernel: groups: lagg Nov 29 11:36:00 <14.6> hermann kernel: media: Ethernet autoselect Nov 29 11:36:00 <14.6> hermann kernel: status: no carrier Nov 29 11:36:00 <14.6> hermann kernel: nd6 options=29 Nov 29 11:36:00 <14.6> hermann kernel: Starting devd. Nov 29 11:36:00 <14.6> hermann kernel: Starting Network: enc0. Nov 29 11:36:00 <14.6> hermann kernel: enc0: flags=0 metric 0 mtu 1536 Nov 29 11:36:00 <14.6> hermann kernel: options=0 Nov 29 11:36:00 <14.6> hermann kernel: groups: enc Nov 29 11:36:00 <14.6> hermann kernel: nd6 options=29 Nov 29 11:36:00 <14.6> hermann kernel: Autoloading module: umodem Nov 29 11:36:00 <14.6> hermann kernel: Starting Network: lagg0. Nov 29 11:36:00 <14.6> hermann kernel: lagg0: flags=8802 metric 0 mtu 1500 Nov 29 11:36:00 <14.6> hermann kernel: options=800000 Nov 29 11:36:00 <14.6> hermann kernel: ether 00:00:00:00:00:00 Nov 29 11:36:00 <14.6> hermann kernel: laggproto failover lagghash l2,l3,l4 Nov 29 11:36:00 <14.6> hermann kernel: groups: lagg Nov 29 11:36:00 <14.6> hermann kernel: media: Ethernet autoselect Nov 29 11:36:00 <14.6> hermann kernel: status: no carrier Nov 29 11:36:00 <14.6> hermann kernel: nd6 options=29 Nov 29 11:36:00 <14.6> hermann kernel: Starting rtsold. Nov 29 11:36:00 <14.6> hermann kernel: Starting dhcp6c. Nov 29 11:36:00 <14.6> hermann kernel: Starting webcamd. Nov 29 11:36:00 <14.6> hermann kernel: webcamd 3447 - - Webcamd is already running for ugen0.6.0 Nov 29 11:36:00 <14.6> hermann kernel: /etc/rc: WARNING: $spmd is not set properly - see rc.conf(5). Nov 29 11:36:00 <14.6> hermann kernel: Waiting 30s for the default route interface: ..... Nov 29 11:36:00 <14.6> hermann kernel: ...... Nov 29 11:36:00 <14.6> hermann kernel: .................. Nov 29 11:36:00 <14.6> hermann kernel: route: message indicates error: File exists Nov 29 11:36:00 <14.6> hermann kernel: add host 127.0.0.1: gateway lo0 fib 0: route already in table Nov 29 11:36:00 <14.6> hermann kernel: route: message indicates error: File exists Nov 29 11:36:00 <14.6> hermann kernel: add host ::1: gateway lo0 fib 0: route already in table Nov 29 11:36:00 <14.6> hermann kernel: add net fe80::: gateway ::1 Nov 29 11:36:00 <14.6> hermann kernel: add net ff02::: gateway ::1 Nov 29 11:36:00 <14.6> hermann kernel: add net ::ffff:0.0.0.0: gateway ::1 Nov 29 11:36:00 <14.6> hermann kernel: add net ::0.0.0.0: gateway ::1 Nov 29 11:36:00 <14.6> hermann kernel: Flushed all rules. Nov 29 11:36:00 <14.6> hermann kernel: 00100 allow ip from any to any via lo0 Nov 29 11:36:00 <14.6> hermann kernel: 00200 deny ip from any to 127.0.0.0/8 Nov 29 11:36:00 <14.6> hermann kernel: 00300 deny ip from 127.0.0.0/8 to any Nov 29 11:36:00 <14.6> hermann kernel: 00400 deny ip from any to ::1 Nov 29 11:36:00 <14.6> hermann kernel: 00500 deny ip from ::1 to any Nov 29 11:36:00 <14.6> hermann kernel: 00600 allow ipv6-icmp from :: to ff02::/16 Nov 29 11:36:00 <14.6> hermann kernel: 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 Nov 29 11:36:00 <14.6> hermann kernel: 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 Nov 29 11:36:00 <14.6> hermann kernel: 00900 allow ipv6-icmp from any to any icmp6types 1 Nov 29 11:36:00 <14.6> hermann kernel: 01000 allow ipv6-icmp from any to any icmp6types 2,135,136 Nov 29 11:36:00 <14.6> hermann kernel: 00000 check-state :default Nov 29 11:36:00 <14.6> hermann kernel: 01200 allow tcp from me to any established Nov 29 11:36:00 <14.6> hermann kernel: 00000 allow tcp from me to any setup keep-state :default Nov 29 11:36:00 <14.6> hermann kernel: 00000 allow udp from me to any keep-state :default Nov 29 11:36:00 <14.6> hermann kernel: 00000 allow icmp from me to any keep-state :default Nov 29 11:36:00 <14.6> hermann kernel: 00000 allow ipv6-icmp from me to any keep-state :default Nov 29 11:36:00 <14.6> hermann kernel: 01700 allow udp from 0.0.0.0 68 to 255.255.255.255 67 out Nov 29 11:36:00 <14.6> hermann kernel: 01800 allow udp from any 67 to me 68 in Nov 29 11:36:00 <14.6> hermann kernel: 01900 allow udp from any 67 to 255.255.255.255 68 in Nov 29 11:36:00 <14.6> hermann kernel: 02000 allow udp from fe80::/10 to me 546 in Nov 29 11:36:00 <14.6> hermann kernel: 02100 allow icmp from any to any icmptypes 8 Nov 29 11:36:00 <14.6> hermann kernel: 02200 allow ipv6-icmp from any to any icmp6types 128,129 Nov 29 11:36:00 <14.6> hermann kernel: 02300 allow icmp from any to any icmptypes 3,4,11 Nov 29 11:36:00 <14.6> hermann kernel: 02400 allow ipv6-icmp from any to any icmp6types 3 Nov 29 11:36:00 <14.6> hermann kernel: 02500 allow tcp from any to me 22 Nov 29 11:36:00 <14.6> hermann kernel: 65000 count ip from any to any Nov 29 11:36:00 <14.6> hermann kernel: 65100 deny { tcp or udp } from any to any 135-139,445 in Nov 29 11:36:00 <14.6> hermann kernel: 65200 deny { tcp or udp } from any to any 1026,1027 in Nov 29 11:36:00 <14.6> hermann kernel: 65300 deny { tcp or udp } from any to any 1433,1434 in Nov 29 11:36:00 <14.6> hermann kernel: 65400 deny ip from any to 255.255.255.255 Nov 29 11:36:00 <14.6> hermann kernel: 65500 deny ip from any to 224.0.0.0/24 in Nov 29 11:36:00 <14.6> hermann kernel: 65500 deny udp from any to any 520 in Nov 29 11:36:00 <14.6> hermann kernel: 65500 deny tcp from any 80,443 to any 1024-65535 in Nov 29 11:36:00 <14.6> hermann kernel: 65500 deny ip from any to any Nov 29 11:36:00 <14.6> hermann kernel: Firewall rules loaded. Nov 29 11:36:00 <14.6> hermann kernel: Starting blocklistd. Nov 29 11:36:00 <14.6> hermann kernel: Starting local_unbound. Nov 29 11:36:00 <14.6> hermann kernel: Waiting for nameserver to start... good Nov 29 11:36:00 <14.6> hermann kernel: /etc/rc: WARNING: /etc/ctl.conf is not readable. Nov 29 11:36:00 <14.6> hermann kernel: /etc/rc: WARNING: failed precmd routine for ctld Nov 29 11:36:00 <14.6> hermann kernel: /etc/rc: WARNING: $iked is not set properly - see rc.conf(5). Nov 29 11:36:00 <14.6> hermann kernel: Clearing /tmp. Nov 29 11:36:00 <14.6> hermann kernel: Creating and/or trimming log files. Nov 29 11:36:00 <14.6> hermann kernel: Updating /var/run/os-release done. Nov 29 11:36:00 <14.6> hermann kernel: Updating motd:. Nov 29 11:36:00 <14.6> hermann kernel: Recovering vi editor sessions:. Nov 29 11:36:00 <14.6> hermann kernel: Starting syslogd. Nov 29 11:36:00 <14.6> hermann kernel: Starting rpcbind. Nov 29 11:36:00 <14.6> hermann kernel: Starting automountd. Nov 29 11:36:00 <14.6> hermann kernel: Starting hcsecd. Nov 29 11:36:00 <14.6> hermann kernel: Mounting late filesystems:. Nov 29 11:36:00 <14.6> hermann kernel: Starting ntpd. Nov 29 11:36:00 <14.6> hermann kernel: Nov 29 11:36:00 <12.3> hermann ntpd[4253]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): expired 155 days ago Nov 29 11:36:00 <14.6> hermann kernel: Starting powerd. Nov 29 11:36:00 <14.6> hermann kernel: Starting dbus. Nov 29 11:36:00 <14.6> hermann kernel: Starting cupsd. Nov 29 11:36:01 <14.6> hermann kernel: Starting cron. Nov 29 11:36:01 <14.6> hermann kernel: Configuring vt: keymap keyrate allscreens_kbd cursor[=0H[=3I[=11F[=0Gvidcontrol: ioctl(CONS_GETCURSORSHAPE): Inappropriate ioctl for device Nov 29 11:36:01 <14.6> hermann kernel: blanktime. Nov 29 11:36:01 <14.6> hermann kernel: Performing sanity check on sshd configuration. Nov 29 11:36:01 <14.6> hermann kernel: Starting sshd. Nov 29 11:36:01 <14.6> hermann kernel: Starting saned. Nov 29 11:36:01 <14.6> hermann kernel: Starting clamav_clamd. Nov 29 11:36:02 <14.6> hermann kernel: Nov 29 11:36:02 <3.3> hermann dhcp6c[3433]: transmit failed: Can't assign requested address Nov 29 11:36:12 <14.6> hermann kernel: Nov 29 11:36:12 <3.3> hermann wpa_supplicant[665]: ioctl[SIOCS80211, op=19, val=0, arg_len=64]: Invalid argument Nov 29 11:36:12 <14.6> hermann kernel: Nov 29 11:36:12 <3.3> hermann wpa_supplicant[665]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Invalid argument Nov 29 11:36:16 <14.6> hermann kernel: sysctl: unknown oid 'hw.acpi.video.lcd0.economy' at line 64 Nov 29 11:36:16 <14.6> hermann kernel: sysctl: unknown oid 'hw.acpi.video.lcd0.fullpower' at line 65 Nov 29 11:36:16 <14.6> hermann kernel: sysctl: oid 'net.inet.ip.fw.default_to_accept' is a read only tunable at line 98 Nov 29 11:36:16 <14.6> hermann kernel: sysctl: Tunable values are set in /boot/loader.conf Nov 29 11:36:16 <14.6> hermann kernel: Starting clamav_freshclam. Nov 29 11:36:16 <14.6> hermann kernel: Waiting for clamd socket.. Nov 29 11:36:16 <14.6> hermann kernel: Starting clamav_milter. Nov 29 11:36:16 <14.6> hermann kernel: Waiting for clamav-milter socket.. Nov 29 11:36:16 <14.6> hermann kernel: Starting background file system checks in 60 seconds. Nov 29 11:36:16 <14.6> hermann kernel: Starting smartd. Nov 29 11:36:17 <14.6> hermann kernel: Nov 29 11:36:17 <14.6> hermann kernel: Sat Nov 29 11:36:17 CET 2025 Nov 29 11:36:34 <14.6> hermann kernel: Nov 29 11:36:34 <3.3> hermann dhcp6c[3433]: transmit failed: Can't assign requested address --MP_/W_I_34BVXS2S2tDXNX6AolW-- From nobody Sat Nov 29 12:15:06 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 4dJTdF1fxsz6HjkP; Sat, 29 Nov 2025 12:15:13 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4dJTdC6LP5z3J43; Sat, 29 Nov 2025 12:15:11 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=QYpNqg0s; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.60 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 9EEB124084C; Sat, 29 Nov 2025 13:15:09 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 184B6240166; Sat, 29 Nov 2025 13:15:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764418508; 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; bh=v2TbFOWdC0C8WPQzDqPyftUnPfMPkNo3lDulYnXSCGY=; b=QYpNqg0sdr11QHM7OGyiXbDB+tz63TwdVhcgRU8QLlOgpsHj106C4xZMYQc8KpY5PMEi/R 45XgumNiCJBfd9at8MJ7fuvHrpDvl8rLtMBlGIvlgq27sTs07wAg40hIVqQG06yzFVghlT ZMSCAgDJns/p+pKRxMNzHqFS7rwnz3rKD901qB8Y5L2CDrY/eYTIY1NlcVCAQx8bLucva/ W0ojGXoNbQQ20iOAvEkBjEyFaMI1xnuko6T7caL/d8SIBlQzUmaVHoM4ykzdvfaDEvMfSY 0ANTn1t1ToG1omNnwYVRFB4VdhK2AJ+VaAW7vql0rxIBBjl/zMxDdOALY3hsMg== Received: from hermann (dynamic-2a02-3100-23f0-d502-33d6-a71c-2660-5263.310.pool.telefonica.de [IPv6:2a02:3100:23f0:d502:33d6:a71c:2660:5263]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id C8A34240123; Sat, 29 Nov 2025 13:15:07 +0100 (CET) Date: Sat, 29 Nov 2025 13:15:06 +0100 From: FreeBSD User To: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: CURRENT: working alternative nVidia GPU driver for x11/nvidia-kmod? Message-ID: <20251129131506.41ceec97@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: aca9c0 X-Rspamd-UID: e51d0e X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.10 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.60:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[walstatt-de.de]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2a02:3100:23f0:d502:33d6:a71c:2660:5263:server fail,85.220.129.60:server fail,85.220.129.53:server fail]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-x11@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4dJTdC6LP5z3J43 Since some recent changes to the CURRENT kernel, x11/nividia-kmod/driver is no longer working. Either kernel module nvidia-modeset.ko/nvidia.ko reject to load with a failure when both the following OIDs are set to ZERO: debug.link_elf_obj_leak_locals=0 debug.link_elf_leak_locals=0 or, if leftto their default (ONE), the kernel module loads results in a blank/black screen, with a carret like one on the console in left upper corner and a immovable mousepointer. On reboot (reboot or shutdown -r now), FreeBSD CURRENT never reboots, last message on console is something everything has been synced. I have to switch OFF and ON the box manually. Since I have a reasonable modern hardware, GPU is a nVidia GTX 5060Ti, I assume that x11-drivers/xf86video-nv isn't an appropriate choice. I'm somehow drifting like a corpse in space here and like to ask whether there is a suitable interim solution at hand whilst the problem with the nVidia BLOB could be fixed? Thanks and best wishes, oh From nobody Sat Nov 29 12:18:12 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 4dJTj41Tcfz6HkPL for ; Sat, 29 Nov 2025 12:18:32 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yx1-xb133.google.com (mail-yx1-xb133.google.com [IPv6:2607:f8b0:4864:20::b133]) (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 4dJTj36NbZz3KH9 for ; Sat, 29 Nov 2025 12:18:31 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yx1-xb133.google.com with SMTP id 956f58d0204a3-6420c08f886so3186600d50.3 for ; Sat, 29 Nov 2025 04:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1764418706; x=1765023506; 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=xaea/hsPFf0pKRjrgzsXSBjz9d2ZB/W3V+ffT4O1lDs=; b=LzWPq8wjtqcNf+9Kks6TzTs4IxgZavJ8VtHVYbTKSZU/N/n29tfVLSDlYo5rL8rwQU yWUE5ajZca031XKWAyoIQkrt0j6aFki/ceeLMqCgRRe6XHe0TK35FAZ1Uyb8tkRR0oco tO9LaTUh/ckox9d4jb2VOCI78FNhXwgKHl9VfFvgNs5KcawPSFoyzsIt3OK1hndNzd9u /bfQtRhTGXuw9Y7O90cPav/lR18BGQGWpc+NWWz+RimrKy9HxbCiEj5UOMV1S4XsLrMW eFE0OQUZhPOfoXetnnlMFOrCH7NnbheqlujZsLd3qpgQAiNCRw5d56XfoytyZmIex9gv 9cKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764418706; x=1765023506; 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=xaea/hsPFf0pKRjrgzsXSBjz9d2ZB/W3V+ffT4O1lDs=; b=Ki8JrKbly+nZcf2BN7KPBj65si+Jik9qT4TFsrZYJJCn+HQ8ck427W+sQnhz0A0Hci tKkY+cs+jC/+vbwsAakyzb4v0DTFD7cLxRFTntYeuZTGBiWZZywItybBZfg5UrZ5/6I4 nnJTL4+vMaUPiUCz8Kt23BSYkaCuOKYfElu9KfcR9v5obUuuqv90fDIurzE04aPoVXhj vDD9VYItqUAevL+15br2TOEFtBOSEgO6Rz1rsST016F7z97frTlMA2x1O7cre2yykgUP 413elycodMAof/XzigrZivgPx5OnbCKmX6UqNIPla8uNsR3eJqlalR6X2xWP+KjNtFlj 0OgA== X-Forwarded-Encrypted: i=1; AJvYcCVYwa7xWFxBIZbvc4OtcLF4cr7qLmTtCYv1xK4XNATMB13PpDWeOO9nlB91w5YcxXtFvXHcdpOMuL8ThoIhlE8=@freebsd.org X-Gm-Message-State: AOJu0YwFzY8ualBetc4fW4XVbzj4Jq6InBgMdfXcaakX/34TzZSgOm+d 3E05/w7VXOJGSXl+w38R8kih0d1eHuc4Lv1M97cHKv+xeLbhH35NYUBz111G871BI2JyptPhRpS NWjg= X-Gm-Gg: ASbGncsYb7LlMFQwMooJqDQ3ZogVCl1D0RitIrmvfTvUKvLr04VWYOZzPbd1MJeOGiL WYluF3SrEe2SxLQIjeVs8eV8v/NfBhTx1tM+U0O/ZdlXwSjNiUyUVK1NA8GeAl4Z7aJh9y468EZ y38XI9WPe3qdLO9iyhRE8IT92NnYHR4xvWKG+8eIRKW6d15BQjfCw1l0ssraj1pSPiEmpHYa7O4 bJZD8iLbEOep8wRLbkFzJpqFwCK5oQ36axIl+IwgpGU6jbAxx+YndCEGCaDlRqUTwBvkiGhBzwf 2hlyBcXDfwJICLqCX+clgH3VeNwGEr5jKg6jiRzwh38w6wi9h5mYrFu+Zd47bZ1W2piXex5WTwV oGlx5yKG/DFmkz2daoHHkHc0m3GDzWVd7WteZoXIc1XiFbcw1frKO1QQi+v5XrxktBZce5peR5w 2SdtoJdaStShjPCHPpOnPn42poz+b/Zthsn/384cH87GY= X-Google-Smtp-Source: AGHT+IHbsY0UfzB5+K58TIjijbFjIjcJjYIvarq0oTct1MVACcDQelD83RCSC9Lcybv0rD/TzU9ITA== X-Received: by 2002:a53:accd:0:20b0:63e:b62:5826 with SMTP id 956f58d0204a3-64302ae8501mr18845820d50.67.1764418705730; Sat, 29 Nov 2025 04:18:25 -0800 (PST) Received: from mail-yx1-f46.google.com (mail-yx1-f46.google.com. [74.125.224.46]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6433c073a70sm2523974d50.8.2025.11.29.04.18.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Nov 2025 04:18:25 -0800 (PST) Received: by mail-yx1-f46.google.com with SMTP id 956f58d0204a3-6420c08f886so3186591d50.3 for ; Sat, 29 Nov 2025 04:18:24 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXeLGePe4ZWDYKKObc1CUDdtMz8btqZ4Vbc2JZxC0VkcXRwYeXpE3eWpcYZtyJZsUUj+Gw58JQzaw89xiSfjUs=@freebsd.org X-Received: by 2002:a05:690c:fcc:b0:788:1c8d:c7c1 with SMTP id 00721157ae682-78a8b5794fbmr281999477b3.70.1764418704525; Sat, 29 Nov 2025 04:18:24 -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: <20251129131506.41ceec97@hermann> In-Reply-To: <20251129131506.41ceec97@hermann> From: Tomek CEDRO Date: Sat, 29 Nov 2025 13:18:12 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bmaW8r9QAAdpbydIzB1f224PLfmXxMLosIEER1gI8ixoixoDiiclDTBh4Y Message-ID: Subject: Re: CURRENT: working alternative nVidia GPU driver for x11/nvidia-kmod? To: FreeBSD User Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org 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)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dJTj36NbZz3KH9 On Sat, Nov 29, 2025 at 1:15=E2=80=AFPM FreeBSD User wrote: > Since some recent changes to the CURRENT kernel, x11/nividia-kmod/driver = is no longer working. > Either kernel module nvidia-modeset.ko/nvidia.ko reject to load with a fa= ilure when both the following > OIDs are set to ZERO: Do you have this set in /boot/loader.conf for the new nvidia gpu? hw.nvidiadrm.modeset=3D1 hw.nvidia.registry.EnableGpuFirmware=3D1 Or this is another problem? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Sat Nov 29 13:25: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 4dJW9t2tb1z6Hr7b; Sat, 29 Nov 2025 13:25:06 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4dJW9t0dgLz3RZ4; Sat, 29 Nov 2025 13:25:05 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 9D2AA240939; Sat, 29 Nov 2025 14:25:03 +0100 (CET) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id C617124021E; Sat, 29 Nov 2025 14:25:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764422701; 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=lueMMe+hmO4GkBuF8O2pAqTosrhR5YoQS6ITbQMeU+Q=; b=eQZCM1v8FQ8kNeO7burcAGzxcEh6l1cXUn6robLDPd5eCr4D81vFPckRm8KLOyK+WMkYCo 746bviDk16KQ99WlG/3Wr4x1bgxY8PXWg7GgGX7QU4V0VHrKZLOZsvtum+IW0Onepv/WVu gsVaDhd5CW3dvNKVxoVvJ1Ctv+t7smaTTxwQnLioIhFrYyhj5ltdjgZLGu9cF4weKshdAT sjvtxbnB0pprSnSV3Foycibthndr4iESADG2mIPiC3Ntwm0h/8v7vqHKKOSH7dGVtwo6QF lR3TNLkLD0AB5bcJbbsEyK5wrgNQcnLqNS+5N8wDhIQ+56r7hjxOEGzBOkFOqw== Received: from hermann (dynamic-2a02-3100-23f0-d502-33d6-a71c-2660-5263.310.pool.telefonica.de [IPv6:2a02:3100:23f0:d502:33d6:a71c:2660:5263]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id 91713240166; Sat, 29 Nov 2025 14:25:01 +0100 (CET) Date: Sat, 29 Nov 2025 14:25:00 +0100 From: FreeBSD User To: Tomek CEDRO Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: CURRENT: working alternative nVidia GPU driver for x11/nvidia-kmod? Message-ID: <20251129142412.1746f00c@hermann> In-Reply-To: References: <20251129131506.41ceec97@hermann> 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 X-Rspamd-UID: 148e3a X-Rspamd-UID: 7dceab X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dJW9t0dgLz3RZ4 On Sat, 29 Nov 2025 13:18:12 +0100 Tomek CEDRO wrote: > On Sat, Nov 29, 2025 at 1:15=E2=80=AFPM FreeBSD User wrote: > > Since some recent changes to the CURRENT kernel, x11/nividia-kmod/drive= r is > > no longer working. Either kernel module nvidia-modeset.ko/nvidia.ko rej= ect > > to load with a failure when both the following OIDs are set to ZERO: = =20 >=20 > Do you have this set in /boot/loader.conf for the new nvidia gpu? >=20 Loading the GPU driver module via /etc/rc.conf.local saves me from crashes/kernel hung in case of a problem, so setting those OIDs in loader.c= onf is ineffective here because the module isn't already loaded. > hw.nvidiadrm.modeset=3D1 > hw.nvidia.registry.EnableGpuFirmware=3D1 I've set hw.nvidia.registry.EnableGpuFirmware=3D1 in /etc/sysctl.conf.local= , the first one not. Loading "kldload nvidia-modeset" after a successful boot of CURRENT. Issuing sysctl hw.nvidia.registry.EnableGpuFirmware=3D1 hw.nvidia.registry.EnableGpuFirmware: 0 -> 1 but for=20 # sysctl hw.nvidiadrm.modeset=3D1 sysctl: unknown oid 'hw.nvidiadrm.modeset' >=20 > Or this is another problem? >=20 > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >=20 From nobody Sat Nov 29 16:45:30 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 4dJbdH32lxz6JDBr; Sat, 29 Nov 2025 16:45:39 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dJbdG4NBGz3sLl; Sat, 29 Nov 2025 16:45:38 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5ATGjULf059589; Sun, 30 Nov 2025 01:45:32 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1764434732; bh=nehnhjnfcA8OdJIimfEZVP0rap4wprqi8CY2gviXLEQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=lQH3EC3lrD/DqrZmeHnFzvzq98NRIH4HTBADAWC7ELnL4JkR6n+8hi1Y4NRrPJEhw cyq3lEyOkvJ+ahtvZ/Lq+bY1/xpFjfYDhf8T5LGq8a5Kigs1bI+NFX1Tm2dzAU0Se4 f5MnDWk40EIgfVsc61w5S2TKyJcMo5LJoaQ+MZhM= Date: Sun, 30 Nov 2025 01:45:30 +0900 From: Tomoaki AOKI To: FreeBSD User Cc: Tomek CEDRO , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: CURRENT: working alternative nVidia GPU driver for x11/nvidia-kmod? Message-Id: <20251130014530.3f8d7fa8efeca2ce99f6a434@dec.sakura.ne.jp> In-Reply-To: <20251129142412.1746f00c@hermann> References: <20251129131506.41ceec97@hermann> <20251129142412.1746f00c@hermann> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: 4dJbdG4NBGz3sLl On Sat, 29 Nov 2025 14:25:00 +0100 FreeBSD User wrote: > On Sat, 29 Nov 2025 13:18:12 +0100 > Tomek CEDRO wrote: > > > On Sat, Nov 29, 2025 at 1:15 PM FreeBSD User wrote: > > > Since some recent changes to the CURRENT kernel, x11/nividia-kmod/driver is > > > no longer working. Either kernel module nvidia-modeset.ko/nvidia.ko reject > > > to load with a failure when both the following OIDs are set to ZERO: > > > > Do you have this set in /boot/loader.conf for the new nvidia gpu? > > > > Loading the GPU driver module via /etc/rc.conf.local saves me from > crashes/kernel hung in case of a problem, so setting those OIDs in loader.conf > is ineffective here because the module isn't already loaded. > > > hw.nvidiadrm.modeset=1 > > hw.nvidia.registry.EnableGpuFirmware=1 > > I've set hw.nvidia.registry.EnableGpuFirmware=1 in /etc/sysctl.conf.local, the > first one not. > > Loading "kldload nvidia-modeset" after a successful boot of CURRENT. > > Issuing > sysctl hw.nvidia.registry.EnableGpuFirmware=1 > hw.nvidia.registry.EnableGpuFirmware: 0 -> 1 > > but for > # sysctl hw.nvidiadrm.modeset=1 > sysctl: unknown oid 'hw.nvidiadrm.modeset' > > > > > Or this is another problem? > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info Please try patch at Bug291212 [1] or review D53987 [2]. Both are actually the same patch. But if this is the case, the offending commit is temporarily reverted now at commit fad4c92b78a123f87195173ac118655fa8e325cd as of "Stabilization Week". So upgrading to it would help, but once the offending commit 9562994a7aacee2baae6ddee1a7b558b48ae39ef is reapplied, the issue would be surely revive without actual fix. And maybe commit e00a781c216cb12603a0a71c9ca293dde3e06250 or later would be wanted if you don't explicitly disabled LINUX option for x11/nvidia-kmod[-devel]. (This is just my prediction, as my main branch environment is too outdated to test. stable/15 and main are installed in different SSDs of exactly the same computer, thus, hard to take time to switch to main and upgrade to test.) [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291212 [2] https://reviews.freebsd.org/D53987 -- Tomoaki AOKI From nobody Sat Nov 29 16:47: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 4dJbgW1JtMz6JDNr for ; Sat, 29 Nov 2025 16:47:35 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yx1-xb136.google.com (mail-yx1-xb136.google.com [IPv6:2607:f8b0:4864:20::b136]) (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 4dJbgV6NL2z3tl2 for ; Sat, 29 Nov 2025 16:47:29 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yx1-xb136.google.com with SMTP id 956f58d0204a3-640d43060d2so2090706d50.2 for ; Sat, 29 Nov 2025 08:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1764434844; x=1765039644; 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=etaAAXHIrDgyBWXbEBehhtMgdK/ZQXEx31kPC+An/dU=; b=iqFZoMnfp0e6pt7f+yaiB9dCEu6PpJsdWzpX5jit5axuCDGC93oBxMyxRvwDm7a6A8 2Uhgp/MSLcO6Og83hHkqyzEtwD0bYAxhoIld1eipDtJr3Pbdtm1V6f2QAc+kJ510DSfz udfk8vQ1i9SRRPrnB3QlvjE4A03FCg59EhXoRaEFbBB8JserdBcPYVZt3s1J2f7t+8eR YXsIeClvC7lhg9pRbrCUOAxCWWVuUgq6quqz6EulB2Fqdk0Vpe17FRvUb0dOmXCuODHk S45om5HJcRt2UsSPc9ZobtFWGIt3ovpNRmYEO/6rRLgQ/8ezv43jUJ1aQNLglyDn03Kv MvGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764434844; x=1765039644; 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=etaAAXHIrDgyBWXbEBehhtMgdK/ZQXEx31kPC+An/dU=; b=X9MP3AghVl13SlAoY3q3WsvFh+Tp6a9qDVtbyycPZrGscCDaNNcu/3CulIiPlhWGGL XMvY1ZttaJ9TRPWlAXeSHa8wlH5t9W7i7yFLh5jjj6XR+e3ZIU87Dw7usIP5PXAYbIWS 68jA0PVyUZX160BjT8cf8a7cgSzyq8P82IxEEUyQ2aQtk9KwzZGgk12fRCQ+TPOCg+6z fO2wemBWoL7vida7yuX6p73YItu+a0Bwg5lONS2K959kcmyjDPXwrUrTFWGNELgXV8Pj cIScnFfrbNoRTxqTVOXzFrPNmLDpTPcy0cVXetEIvIpobYS8JKQxtmCCm4+Cz1Mxnyy0 jJMA== X-Forwarded-Encrypted: i=1; AJvYcCV0+60B+Q8oo29xD+gdYWno5X3cyvLTdNLcbZR7+/hNaBz6hd9FtooBk5i1Wo83PFbv04J9Ui3NLSG+SWCIJxY=@freebsd.org X-Gm-Message-State: AOJu0YyOIjfBb1eWy34/unLXTPm0+GWjgxge1r2VE34NEk2yoVuSvqJH ut8yt/6wKpHy9QbFDPb2OAQD0yySaFmeUYHgIEsF0UUCXA6f1mRvxYcjGK9rvO7oSdidHv2UrQx Jx2w= X-Gm-Gg: ASbGncs9ytUkYUVKpz7ZIyH7f35TtQasetl9MFmolsqVLohZYtRNzNN/q+HZpuK8dJ1 66KhrigTZWao/IYbV3RptZyc/H6mTor1DIJ3bjMx6q+xTRZ30yaekwuWTS8RL3IVAprsfrxK5CS 5zxBCXCpv8oZwa8JjuedTaIhLC0LYguqm55p0EuOSnUoorzDyA98PqK6bcg0PJYN3xHjTGkGcKF Q5SBGW1YvW109yaEVCR5Qz057QgE+zH2B2aILUFv2KbJ6v7K+nW3a4yk/A0ggteI3JnzDUptHFB OZTx27hNmC7ZuhsTm1lQUjXgY9fWd7gMSQrPoQlygq+5iYsaA7x8qoTAeqio2x/GySr+WIlVhRB uiJDqQrWKVs8zWcmEWkT6EXK3lAfog2Vz6Y/e0GimswcLlsyj2PeJxI6/5O15F2V1PIhTWJumZ+ x+CkcSH1ObsYBkMcxvP18x+jnH6xKDFDW9x/+3As1wB/g= X-Google-Smtp-Source: AGHT+IGeyNAx0JOes3HFJT/tbuaeDYFDcd7jyJFpZJ3aV2k1ucaGJJbem++iaof/VXDYaKwrT0jHZQ== X-Received: by 2002:a05:690e:1589:10b0:63e:1df9:c895 with SMTP id 956f58d0204a3-64302adf0d3mr16682419d50.66.1764434843832; Sat, 29 Nov 2025 08:47:23 -0800 (PST) Received: from mail-yx1-f44.google.com (mail-yx1-f44.google.com. [74.125.224.44]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6433c443360sm2717533d50.13.2025.11.29.08.47.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Nov 2025 08:47:23 -0800 (PST) Received: by mail-yx1-f44.google.com with SMTP id 956f58d0204a3-642f3bab0c8so2239578d50.0 for ; Sat, 29 Nov 2025 08:47:22 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWmuIaB9eq93ywEqT8STMv+qCESfVXQlUbVV86TDyFohmSHjtGNyemuMN3cPDKghFeam6xjd29lF+WV74pGLC0=@freebsd.org X-Received: by 2002:a53:ead2:0:b0:641:f5bc:6970 with SMTP id 956f58d0204a3-64302af375fmr17612969d50.76.1764434842602; Sat, 29 Nov 2025 08:47:22 -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: <20251129131506.41ceec97@hermann> <20251129142412.1746f00c@hermann> In-Reply-To: <20251129142412.1746f00c@hermann> From: Tomek CEDRO Date: Sat, 29 Nov 2025 17:47:10 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bn2bEY7aS6O4UNa4nTjR9cDS3XA2ozDxvIifOnaPgafI-auXi8iZtEfwew Message-ID: Subject: Re: CURRENT: working alternative nVidia GPU driver for x11/nvidia-kmod? To: FreeBSD User Cc: freebsd-x11@freebsd.org, freebsd-current@freebsd.org 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)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dJbgV6NL2z3tl2 On Sat, Nov 29, 2025 at 2:25=E2=80=AFPM FreeBSD User wrote: > I've set hw.nvidia.registry.EnableGpuFirmware=3D1 in /etc/sysctl.conf.loc= al, the > first one not. Please try setting this `hw.nvidia.registry.EnableGpuFirmware=3D1` exactly in /boot/loader.conf and reboot. This needs to be set on boot and before module is loaded not after :-) `hw.nvidiadrm.modeset=3D1` seems to be leftover from an old releases my bad sorry :-P Is this your first run of this GPU on this system or it worked fine before (i.e. 14 or earlier 15)? If it worked as intended and only breaks after changing `debug.link_elf_obj_leak_locals=3D0` and `debug.link_elf_leak_locals=3D0` on recent 15 then this is a different issue sorry for the noise.. and it would be best to provide some backtrace / logs :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Sat Nov 29 17:27: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 4dJcYd4tX5z6JJC0 for ; Sat, 29 Nov 2025 17:27:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) (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 4dJcYd2vDyz40RD for ; Sat, 29 Nov 2025 17:27:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-787d5555274so27390697b3.1 for ; Sat, 29 Nov 2025 09:27:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764437252; x=1765042052; 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=qT987QbkBUD0b2BuFY5uZbF9vGZlTm5k9vGzcTdhoJk=; b=SjI7sYLbL9NMPTeENJ+v9g+q+iYCYV7EMQT9nen566D241O+NbWotdI4QuBu2HdOZQ uKQQrNVqFozMpfmD1aMk9GNRt9jfALmAFg0DhN8gR7G5oCociPLu84aNATxvsWcDkWZj 2xwpBohf3I0O9dujYvFkSYKTHm2iFEkkXezv4KGEXiEi0lIHvGF1WvNPJum0f0XAh+jP QiC+DZYeZ+qGYNMnWTYTpf0v9HJ+LdHm7R8Qox4ZK/WU5MlL2WRAO8S7t+HF2i2bnypy EMNfrVel3LqKOOxT1IKm3IXb6tUFJ7xdMcHDO+G6VsvPCBnY9lOihXgMQ9B7JTVXtSLi oWYA== X-Forwarded-Encrypted: i=1; AJvYcCUofuXZgKovBRyec01XKe1lZ8vDsOdJR545Cp/BpRunDJCMEaYM2gPK9C9nK85SE1zaZUiMZ3GlQbOyX8T7s2E=@freebsd.org X-Gm-Message-State: AOJu0YzYffzGqdrEs91tri3zKhokOoqH4FWnWMScJovJ5SZ6c6vs5V7L 2ZXfu38W207Pc0QPp/OJQNCuohX5siiS6Bb5arwnAg8kHu3IRYhUfGpAPnJQhMk15PZsmRUINZP v2Mc3MWes2fYDzsNkHzSOJz/3SYovS9Q= X-Gm-Gg: ASbGncuWOC2T4jXrPv5iD3WvXnMFea5HW64Bx/S8Rpw0gkzZJMd9GSwfxBmn1EE9sGd QA7D5Lz4geIk6Qt9l4mrdEXQaz74hDzWDTqwMSUuSlFnWjieX2ImCRtzhaK2HEJU//xtNWPN0lQ QB7pAmtCNQxxijgBylVmGcgx5VOIEMXpFeCMeKyqr1/F6c8oqbmsCHpZgt4/AJWsx7IXHiK+zCr 7s8IsnUFxkN46pxvikJHbwe/9BirrfEXJi/iyPMjL9xdO3wdTcNEBvkbNoGN5a8skGU/PCZxHrU g56s1GzE5e9Z/ZyOJ4J007of X-Google-Smtp-Source: AGHT+IEBOVhEzcuGe65inRudys1taF+0lq7p7ATtjG8LdoWhLR6tugWyf8esBpkFgWI5LFJIB2rYm+n33bA7raWSzZ4= X-Received: by 2002:a05:690c:6a85:b0:784:1f81:8c39 with SMTP id 00721157ae682-78ab6f72acamr175548667b3.59.1764437252258; Sat, 29 Nov 2025 09:27:32 -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: <20251129131506.41ceec97@hermann> <20251129142412.1746f00c@hermann> In-Reply-To: From: Adrian Chadd Date: Sat, 29 Nov 2025 09:27:20 -0800 X-Gm-Features: AWmQ_bn10_DjJo_al8uhBoNJnwLBE69KwkgKfUeDP84-HaXRZ4gVdh_3dwzyh4M Message-ID: Subject: Re: CURRENT: working alternative nVidia GPU driver for x11/nvidia-kmod? To: Tomek CEDRO Cc: FreeBSD User , freebsd-x11@freebsd.org, freebsd-current@freebsd.org 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: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: 4dJcYd2vDyz40RD hi! On Sat, 29 Nov 2025 at 08:48, Tomek CEDRO wrote: > > On Sat, Nov 29, 2025 at 2:25=E2=80=AFPM FreeBSD User wrote: > > I've set hw.nvidia.registry.EnableGpuFirmware=3D1 in /etc/sysctl.conf.l= ocal, the > > first one not. > > Please try setting this `hw.nvidia.registry.EnableGpuFirmware=3D1` > exactly in /boot/loader.conf and reboot. This needs to be set on boot > and before module is loaded not after :-) > > `hw.nvidiadrm.modeset=3D1` seems to be leftover from an old releases my > bad sorry :-P When did that change? I have hw.nvidiadrm.modeset=3D1 in my /boot/loader.conf from when I set this up earlier in this year. -adrian From nobody Sat Nov 29 17:49:40 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 4dJd3L1W7jz6JKyG for ; Sat, 29 Nov 2025 17:49:50 +0000 (UTC) (envelope-from drsnx60@gmail.com) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 4dJd3K4FClz431H for ; Sat, 29 Nov 2025 17:49:49 +0000 (UTC) (envelope-from drsnx60@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-5958232f806so3243237e87.0 for ; Sat, 29 Nov 2025 09:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764438582; x=1765043382; darn=freebsd.org; h=in-reply-to:organization:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=YxGEN279kDhiakb9H4puG6f0D55fVKV8iaDwXSeHRBI=; b=OiUDG0tvRSlTHUrdhrWKAg/aqpmTzXGY0y3LOEYIN9sDzZdYpXAC9FdQek+eUS1wav HAQZNPNQ6iHlYmJbFFYe7EymqAxjEpqiisTxXESmxHyw5wQC+t59F6tx4bVPOUOl1S1M SzdByVCGdYeob3A++UitfGK6SOHZhE0QgnHshm7BHHKLaBHU/R0T7vg47THzTGHiAwg2 V9JNqkRQJWxrJpJuKr1t428mmM0KrSVoJCxkhmToUJ6kdADqL7taPxsYB/mCLYoFo59i gQ2EbQE7MGeEz/+gyoMfq0VPtXc3YIRI6JTYK75HvIqUhO9Z7sAgePH+r15eROUQxV+t v9vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764438582; x=1765043382; h=in-reply-to:organization:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YxGEN279kDhiakb9H4puG6f0D55fVKV8iaDwXSeHRBI=; b=JypFZmBsNZFNcet5/ue/Y0ZEC3cSEAgwZ5nAcVzqlSMQIByXUt1Ls9XQT6yvDH+XYu ZYCm4B2r5BpcgAwUWg2VZPQi9XYYCjWDo99943X+Nm1IjCjkxljb4bILlabILJGXo2dT rUFqmkNjo69Rjs/y8C/VybxKQ8jq8NKLtU8VcB0qxf4aXTb9bDCt9B9evTubmrt/WZEW u1sHP/MNTpJqDDdW8CM3oPinhGgh0RmDwcQHeBm3pJelu6n2SLSKccZTXR7Ft9rVcHYS 7wVQW4UxK+JO4dTlEWGlcmy8wjgT7E93CfjBVSNdunNHFOsZWK+4niR8IBHpQvYdOU2s EOWg== X-Forwarded-Encrypted: i=1; AJvYcCUuD1Tr8Dr7ur3spj1AQ+AmqDJfr9ODge+i1MpgR6vEIU656/rMZd9F9pHGgulxDKrzlO5nFCGS4nQ2vxqddB0=@freebsd.org X-Gm-Message-State: AOJu0Yy8ieNlDBE+d+4Qkx5aixbElObQR4QU6Nvk9SiaHIXE3IqHZPLc M3iGvi+DiB5mWZT3Vqo1e+3AX4WyOVm+E7WKqWzG7Zo0LDOhABC/YEzh/5u39P5o X-Gm-Gg: ASbGnctZgJR0GN2sWNbzD7OisAnWTq6DShSBWEaZ+M0Fep/8SBPbIqFerwWQUCpktMp 4LY3CIgkajEU6DvGSEjEESPYn8NzC2/el6p6y5lhsEswFnPSQaJWVytS8aAZCOvl/gveqIPr4Du J2Yf7SvSrGgaYOK8rrn3Dh1ax6EpU4h+3Esmcac6jHh7V06BqfoWl5v7x0AmIJ/dDvD6coc2rAl RrbwS0IdHomwWWNrqCMg6sOsakI8MR8CYH0v8YigJ6DdRuw0ZlYTPuh7tsQlInPtcUglXjnjQdA N8skaJLlK1u99lFJceN1HLIoF9k39kwRoJgPCMrVp7l4bprQl4uk6SlHi5kfk+g3cr149JrK37O Lmr6epBiczPSk3maHBqPYqVgTasBqThqAh+MdvZiMeGQ0J7dRJzo+CLkUP5Q/M3u5CDDpnHNBYN sbiHfKlovCE2e+4rfss0aeLu8g0S8xB1qGqg== X-Google-Smtp-Source: AGHT+IGQ+ffMZk+ZZd6J9MiSk1k3GFEH9/duIuHylE2EwPegMKgk6sLu8P/3qox4abTSt4NzhANNlw== X-Received: by 2002:a05:6512:3f18:b0:595:8200:9f8f with SMTP id 2adb3069b0e04-596a3ebb042mr9695287e87.18.1764438581363; Sat, 29 Nov 2025 09:49:41 -0800 (PST) Received: from [192.168.2.131] (host.62.13.8.86.bitcom.se. [62.13.8.86]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-596bfa48ab5sm2126697e87.72.2025.11.29.09.49.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Nov 2025 09:49:41 -0800 (PST) Content-Type: multipart/alternative; boundary="------------ZyYuorEsNZhvxSkvAYzFnOfi" Message-ID: <141caf69-dde9-4c3a-b406-145146b3189d@gmail.com> Date: Sat, 29 Nov 2025 18:49:40 +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 Subject: Re: CURRENT: working alternative nVidia GPU driver for x11/nvidia-kmod? To: Adrian Chadd , Tomek CEDRO Cc: FreeBSD User , freebsd-x11@freebsd.org, freebsd-current@freebsd.org References: <20251129131506.41ceec97@hermann> <20251129142412.1746f00c@hermann> Content-Language: sv-SE From: Lars Tunkrans Organization: Retiered 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: 4dJd3K4FClz431H This is a multi-part message in MIME format. --------------ZyYuorEsNZhvxSkvAYzFnOfi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Den 2025-11-29 kl. 18:27, skrev Adrian Chadd: > hi! > > On Sat, 29 Nov 2025 at 08:48, Tomek CEDRO wrote: >> On Sat, Nov 29, 2025 at 2:25 PM FreeBSD User wrote: >>> I've set hw.nvidia.registry.EnableGpuFirmware=1 in /etc/sysctl.conf.local, the >>> first one not. >> Please try setting this `hw.nvidia.registry.EnableGpuFirmware=1` >> exactly in /boot/loader.conf and reboot. This needs to be set on boot >> and before module is loaded not after :-) >> >> `hw.nvidiadrm.modeset=1` seems to be leftover from an old releases my >> bad sorry :-P > When did that change? I have hw.nvidiadrm.modeset=1 in my > /boot/loader.conf from when > I set this up earlier in this year. > > > > -adrian > *Even today in 16-current the pkg-message file for nvidia-drm-kmod-580.105.08 says :* Modesetting must be enabled to use nvidia-drm.ko for graphics. This can be done by setting the modeset sysctl, the equivalent of the modeset kernel parameter on Linux. hw.nvidiadrm.modeset=1 This must be set before loading nvidia-drm.ko, most easily done by placing the above in /boot/loader.conf. -- ------------------------- Lars Tunkrans Oracle SPARC/Solaris System Administrator Fujitsu M12 SPARC Specilaist --------------ZyYuorEsNZhvxSkvAYzFnOfi Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


Den 2025-11-29 kl. 18:27, skrev Adrian Chadd:
hi!

On Sat, 29 Nov 2025 at 08:48, Tomek CEDRO <tomek@cedro.info> wrote:

On Sat, Nov 29, 2025 at 2:25 PM FreeBSD User <freebsd@walstatt-de.de> wrote:

I've set hw.nvidia.registry.EnableGpuFirmware=1 in /etc/sysctl.conf.local, the
first one not.

Please try setting this `hw.nvidia.registry.EnableGpuFirmware=1`
exactly in /boot/loader.conf and reboot. This needs to be set on boot
and before module is loaded not after :-)

`hw.nvidiadrm.modeset=1` seems to be leftover from an old releases my
bad sorry :-P

When did that change? I have hw.nvidiadrm.modeset=1 in my
/boot/loader.conf from when
I set this up earlier in this year.



-adrian


Even  today  in  16-current  the pkg-message file  for nvidia-drm-kmod-580.105.08  says  :

Modesetting must be enabled to use nvidia-drm.ko for graphics. This can be done
by setting the modeset sysctl, the equivalent of the modeset kernel parameter
on Linux.

hw.nvidiadrm.modeset=1

This must be set before loading nvidia-drm.ko, most easily done by placing the
above in /boot/loader.conf.


-- 
-------------------------
Lars Tunkrans
Oracle SPARC/Solaris System Administrator
Fujitsu M12 SPARC Specilaist
--------------ZyYuorEsNZhvxSkvAYzFnOfi-- From nobody Sat Nov 29 17:52: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 4dJd6B4441z6JLDQ for ; Sat, 29 Nov 2025 17:52:18 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yx1-xb135.google.com (mail-yx1-xb135.google.com [IPv6:2607:f8b0:4864:20::b135]) (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 4dJd6B0rypz44Nl for ; Sat, 29 Nov 2025 17:52:18 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yx1-xb135.google.com with SMTP id 956f58d0204a3-6420c08f886so3360149d50.3 for ; Sat, 29 Nov 2025 09:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1764438735; x=1765043535; 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=siFmqRZZMt1tDQEiSXFOnlkuBkWOsHkIxcLnjfATaq4=; b=apiNAJRW3SKdhmGkCRm/LMn2PleA2ikfVeLFHJfurNibC1zKd2aP6xlVoXrpLoc+ta JT2X1JzWmBkhu3S31Od9iL/uAxUMHHKw2BqNbIC4mFJa3sKLN4MoABjfz+SuXkyU29dX K/t0pmtnM+vEtEAmcMZy9A+/QamCbdk3Fc/ob2rdc8hioIhOqQyUkD2xdTCoVz8ly3aT hqqYV5iwl3+90JyOkHezfDfB3/OC5HOvVYc5rGr5WYmDNh0vJwkXebd0Q4gJJ8zLuSnn S2KCWi2LkSAwPqLDyZ1ziUVMIPR3h3Dm+VKp/LoUqJb4wXdtL86g2Ceop2WGjnRszcwN T6yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764438735; x=1765043535; 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=siFmqRZZMt1tDQEiSXFOnlkuBkWOsHkIxcLnjfATaq4=; b=X9Dcon1YnBEtVJVYtoY8+kunb8Orjm9FpVT0aHs3KmfR08euuqnFH0DlUFWNkKRZ6f MRZZ2BrhCPKjU7U6qat81aFUEKfNeeZjjjqW06c1AL+nfiQYOWNcpu2VqFtExVhTo6Mj 6VFLej8iKzXPSiIJR4kz0RmBWacT+PTE2EnadSjnybzhBkzZNAkQ/S6q7RLCH4Y75Hm9 H0xsw7ZNMlaHngmOcapt3aPDzBlWcqSadj7hHlF9vNyE5srPNMzxmF4VDCvqkFZv8ab7 3jVd33xn3IuJ7MNJRMVQ6cuW66EBD/1KmFgup5WqwywnyjULh7qDq8NFcb6FuikgoHfK OxoA== X-Forwarded-Encrypted: i=1; AJvYcCUcLK8vcGYBVVzmDrH5BDzZIPU7aTQxSetXiaZBcFjazElwcvQ8ZGZ150asT7unyMVFQPXXhdNTeWzafmRFc34=@freebsd.org X-Gm-Message-State: AOJu0YwKvez3TocuKdf4bEb7Wi5JntbvX+HMI3m0ubOdFXzcBiThUCBo z9EsLniA6K8UIEaNNFfSFOSliobkgCTzbOVAI+Qumme9z5bLMbmUyYwoPFkWFJzLMWi6dJMGnGI VZ8g= X-Gm-Gg: ASbGncua3Ht6nouk9K4ROr0U9K3A2dI/knkxjLTDeqw7yE7/1mE+X5Chv0WOuZ/sFkb 1RAPqnGG2ZI2rnZecWKCKEg+1sVVbWS3CecdEogNb9Z0YwcEuxjYTMZYHYnqO7k6q6gathcELcW EAXUWVVtu+eDD1vsqO8Y4zNLy3OcSItAO98FJp41R57ZhrKPDKXHzjFbrJ1xzj2hBr6FZ/+OWHT IhcIa3Bp3ErQAsvi1pXTwKsQ6bbGH8HAplPNIVk1C3jKBaZ5L6D6ysGZUtIIXahEpk6VeQy+Mw5 FG8LeCiAUUcYkW/+fkyGQQyin2CliGZKECHK+OCfsgOn1YJLpBH3Gea2lD/ph/mN3RA2YiIo6Tt vtps1OBH7KyuKrtdEVWFt8PU0Ru2K8T17MyjLlT8fZX2Q5zRa4y9rZjhpc7pB9Vre2g9vIfg6E4 aHi/KYgr1DiuX2obPN4wU4Y4VEYFXpgtOxzJx1q3oRYT8hC8U= X-Google-Smtp-Source: AGHT+IHzd7M40D2IcdAqwSgFm58UvCjX4gan1jnBJYviWWRAWtkYJL7KnQoBzXX82PS4YDt26kC3Vw== X-Received: by 2002:a05:690e:2501:10b0:640:dd53:71aa with SMTP id 956f58d0204a3-64302ac0233mr20152784d50.46.1764438735463; Sat, 29 Nov 2025 09:52:15 -0800 (PST) Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com. [209.85.128.169]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78ad0d66f38sm27934307b3.23.2025.11.29.09.52.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Nov 2025 09:52:15 -0800 (PST) Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-78ab03c30ceso24355237b3.2 for ; Sat, 29 Nov 2025 09:52:13 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXqGLF/dW9+l3FmBwR8rKF5n8eUuQ1GbkNYa4oagkZ9Of+MBRZCrEjTSAWj7MH/eVh0H54+us+Cc91brg87zQA=@freebsd.org X-Received: by 2002:a05:690c:6a06:b0:787:e9bc:fa85 with SMTP id 00721157ae682-78a8b5780demr272980407b3.68.1764438733484; Sat, 29 Nov 2025 09:52:13 -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: <20251129131506.41ceec97@hermann> <20251129142412.1746f00c@hermann> <141caf69-dde9-4c3a-b406-145146b3189d@gmail.com> In-Reply-To: <141caf69-dde9-4c3a-b406-145146b3189d@gmail.com> From: Tomek CEDRO Date: Sat, 29 Nov 2025 18:52:01 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_blts_5wy2iGz4HNT8s2MWrIXeWsUfS9QrgCsg6zrpencbzp3Sf3y8VAH2Q Message-ID: Subject: Re: CURRENT: working alternative nVidia GPU driver for x11/nvidia-kmod? To: Lars Tunkrans Cc: Adrian Chadd , Tomek CEDRO , FreeBSD User , freebsd-x11@freebsd.org, freebsd-current@freebsd.org 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)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dJd6B0rypz44Nl On Sat, Nov 29, 2025 at 6:49=E2=80=AFPM Lars Tunkrans w= rote: > Den 2025-11-29 kl. 18:27, skrev Adrian Chadd: > hi! > On Sat, 29 Nov 2025 at 08:48, Tomek CEDRO wrote: > On Sat, Nov 29, 2025 at 2:25=E2=80=AFPM FreeBSD User wrote: > I've set hw.nvidia.registry.EnableGpuFirmware=3D1 in /etc/sysctl.conf.loc= al, the > first one not. > > Please try setting this `hw.nvidia.registry.EnableGpuFirmware=3D1` > exactly in /boot/loader.conf and reboot. This needs to be set on boot > and before module is loaded not after :-) > > `hw.nvidiadrm.modeset=3D1` seems to be leftover from an old releases my > bad sorry :-P > > When did that change? I have hw.nvidiadrm.modeset=3D1 in my > /boot/loader.conf from when > I set this up earlier in this year. > > Even today in 16-current the pkg-message file for nvidia-drm-kmod-58= 0.105.08 says : > > Modesetting must be enabled to use nvidia-drm.ko for graphics. This can b= e done > by setting the modeset sysctl, the equivalent of the modeset kernel param= eter > on Linux. > > hw.nvidiadrm.modeset=3D1 > > This must be set before loading nvidia-drm.ko, most easily done by placin= g the > above in /boot/loader.conf. ACK! Sorry I did not find it in `sysctl -a | grep hw.nvidiadrm.modeset` and I thought its gone my mistake! :-( -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Sat Nov 29 18:11: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 4dJdXx0TSjz6HdjG; Sat, 29 Nov 2025 18:12:01 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dJdXw3SdQz46jY; Sat, 29 Nov 2025 18:12:00 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 5ATIBq9H071709; Sun, 30 Nov 2025 03:11:53 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1764439913; bh=y8GfxKzNDrr0xD8ECcPCCOpO5mFbn1J8wbz++48iBD0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=heTIOSbc99+RCHB/CWmhlvmX7mTfbZEsykfVJvvVoLrvmMPCtkATzgpxmNhbyLOMo gzsYGEogdFWRjnkxQM8xl9XAtxYXat/X4Rqkl/b53yRSkkXf/RySkSZoEm5YZqpKG3 41NvGPUQyNIpsyoeQbYAQV6BuiQcsZq2fSr83ems= Date: Sun, 30 Nov 2025 03:11:52 +0900 From: Tomoaki AOKI To: Adrian Chadd Cc: Tomek CEDRO , FreeBSD User , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: CURRENT: working alternative nVidia GPU driver for x11/nvidia-kmod? Message-Id: <20251130031152.26d137aabc454996c6787954@dec.sakura.ne.jp> In-Reply-To: References: <20251129131506.41ceec97@hermann> <20251129142412.1746f00c@hermann> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dJdXw3SdQz46jY On Sat, 29 Nov 2025 09:27:20 -0800 Adrian Chadd wrote: > hi! > > On Sat, 29 Nov 2025 at 08:48, Tomek CEDRO wrote: > > > > On Sat, Nov 29, 2025 at 2:25 PM FreeBSD User wrote: > > > I've set hw.nvidia.registry.EnableGpuFirmware=1 in /etc/sysctl.conf.local, the > > > first one not. > > > > Please try setting this `hw.nvidia.registry.EnableGpuFirmware=1` > > exactly in /boot/loader.conf and reboot. This needs to be set on boot > > and before module is loaded not after :-) > > > > `hw.nvidiadrm.modeset=1` seems to be leftover from an old releases my > > bad sorry :-P > > When did that change? I have hw.nvidiadrm.modeset=1 in my > /boot/loader.conf from when > I set this up earlier in this year. > > > > -adrian Maybe the issue below is affecting indirectly. At commit 9562994a7aacee2baae6ddee1a7b558b48ae39ef, tunable debug.link_elf_obj_leak_locals was flipped to 0 (true), causing nvidia.ko with default options of x11/nvidia-kmod* to fail loading, causing nvidia-modeset.ko to fail, then, nvidia-drm.ko to fail, too. Even without LINUX option enabled (non-default), nvidia-modeset.ko still fail as of the lack of (formerly available) local symbols in nvidia.ko. And nvidia-drm.ko wants local symbols in nvidia-modeset.ko. Patch at Bug 291232 (the same patch is available via review D53987) would fix the issue. Note that commit 9562994a7aacee2baae6ddee1a7b558b48ae39ef is temporarily reverted at commit fad4c92b78a123f87195173ac118655fa8e325cd. And I predict commit e00a781c216cb12603a0a71c9ca293dde3e06250 would allow linux*.ko to be loaded, thus, LINUX option would hopefully become safe to enble again. (I've put links to the PR and review in another post.) I have only one computer for FreeBSD, having 2 SSDs for stable/15 and main respectively, so to test on main, I need to reboot into main environment (which is outdated and need upgrading first to obtain commit e00a781c216cb12603a0a71c9ca293dde3e06250). So untested on main branch, nor on recent models of GPUs. Regards. -- Tomoaki AOKI From nobody Sat Nov 29 18:37: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 4dJf750Bvpz6HhpF for ; Sat, 29 Nov 2025 18:38:09 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (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 4dJf744Tq5z3Dq7 for ; Sat, 29 Nov 2025 18:38:08 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 684DB24078B; Sat, 29 Nov 2025 19:37:57 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id CC20724074D; Sat, 29 Nov 2025 19:37:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1764441475; 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=YJEWcC7mM2fsCJPANMR6+f7qU6Le8QKM16wP4fbNc5s=; b=oiw4FstQHTDRSTpGWcvK8n0bs3Z2bImBmMja5kRU/ekfQiBMFKyrmNblAQDuETahEJApiA Y7PMLd/WEWbZn7fCoBVZ4DhxW/V1nUwftLoBaMkFbvPLkdC0wp3I12A5MgNwGrJhOVYW4M 4k5YhxF8rOssXDe/Dm9QMPNj71JedFLtJ+fXUuSxqoBuz29U6/gNSlHVuhpmee8wcdxD0O FW/JJNGz2GKtZMhoNv5OhqXhU5GsPXnoSyvLwi9VY0OQIQ1YeDCxp7hFsXAIozxBaL4YYi tkuzeXDJl9OiRTo87+wfNp133bP5Vnnl8YqbJ4agexVcuXAeRGqrfJtyLw1NgQ== Received: from thor.sb211.local (dynamic-2a02-3100-23f0-d502-021b-21ff-fe4e-8f4d.310.pool.telefonica.de [IPv6:2a02:3100:23f0:d502:21b:21ff:fe4e:8f4d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 7E2C8240459; Sat, 29 Nov 2025 19:37:55 +0100 (CET) Date: Sat, 29 Nov 2025 19:37:21 +0100 From: A FreeBSD User To: Warner Losh Cc: FreeBSD CURRENT Subject: Re: freezing on unmountin ext2fs USB device Message-ID: <20251129193738.29f4a1f3@thor.sb211.local> In-Reply-To: References: <20251123151439.361dd84c@thor.sb211.local> <20251128062140.120e8369@hermann> <20251129095452.5905b7d5@hermann> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd16.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/CZs8u8qKZNUFV84ak0RVn5."; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 66a98f X-Rspamd-UID: d3faae 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: 4dJf744Tq5z3Dq7 --Sig_/CZs8u8qKZNUFV84ak0RVn5. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tage des Herren Sat, 29 Nov 2025 03:32:09 -0700 Warner Losh schrieb: > On Sat, Nov 29, 2025 at 1:59=E2=80=AFAM FreeBSD User wrote: >=20 > > On Thu, 27 Nov 2025 23:33:50 -0700 > > Warner Losh wrote: > > =20 > > > On Thu, Nov 27, 2025, 10:22=E2=80=AFPM FreeBSD User =20 > > wrote: =20 > > > =20 > > > > On Tue, 25 Nov 2025 21:03:01 -0700 > > > > Warner Losh wrote: > > > > =20 > > > > > On Sun, Nov 23, 2025 at 7:15=E2=80=AFAM A FreeBSD User < =20 > > freebsd@walstatt-de.de> =20 > > > > > wrote: > > > > > =20 > > > > > > Hello, > > > > > > > > > > > > running FreeBSD 16.0-CURRENT #4 master-n282101-c8cf5a99f82b: Su= n =20 > > Nov 23 =20 > > > > > > 13:56:23 CET > > > > > > 2025 amd64 I'm running into a serious problem when mounting an = =20 > > ext2fs =20 > > > > > > formated USB Flash > > > > > > device (512GB). The devince contains files written by a Linux = =20 > > system, =20 > > > > > > mounting the USB Flash > > > > > > via extended4fs, the size of the written datafiles is > 128GB. = =20 > > Deleting =20 > > > > > > those files larger > > > > > > than some 20GB results in an I/O error reported by FReeBSD (# s= udo =20 > > rm =20 > > > > > > /mnt/USB/filename). > > > > > > Unmounting the ext2fs after deletion (sudo umount /mnt) results= in =20 > > a =20 > > > > total =20 > > > > > > freeze of the box. > > > > > > No crash, no core dump, nothing. I waited almost an hour hoping= for > > > > > > recover. I have to > > > > > > physically switch off the box. > > > > > > > > > > > > I checked with other USB flash I have at hand, one Samsung 256 = GB, =20 > > ZFS =20 > > > > - =20 > > > > > > no problem, another > > > > > > 128GB, UFS, no problem and several much smaller (4 - 64GB) with= =20 > > FAT or =20 > > > > UFS =20 > > > > > > filesystems, all no > > > > > > problem. > > > > > > > > > > > > I can not figure out whether it is the USB flash drive itself, = =20 > > the =20 > > > > size or =20 > > > > > > the ext2fs itself > > > > > > causing the problem. > > > > > > > > > > > > Does anybody see similar problems or do have an tip to =20 > > investigate =20 > > > > without =20 > > > > > > risking my box' > > > > > > health switching it on/off on failure? > > > > > > =20 > > > > > > > > > > I've not seen this on the smaller tests I've been able to run. > > > > > > > > > > So can you share the error messages that you get when you say you= =20 > > get I/O =20 > > > > > errors? I'd like to see if this is due to an error in ext2fs or o= n =20 > > the =20 > > > > USB =20 > > > > > drive. It's kinda sounding a little like the particular USB is =20 > > triggering =20 > > > > > some kind of issue that at the very least we should work around. = =20 > > Given =20 > > > > that =20 > > > > > it's not happening on all ext2fs drives you try to access, I'm =20 > > leaning =20 > > > > > towards the drive, but you never know. > > > > > > > > > > Thanks =20 > > > > > > > > Plugging the USB flash gives the following hardware information on = the > > > > console: > > > > > > > > [...] > > > > ugen1.5: at usbus1 > > > > umass0 on uhub6 > > > > umass0: on usbus1 > > > > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 0= 0 =20 > > 00 10 =20 > > > > 00 00 > > > > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > > > > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > > > > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 =20 > > (Invalid =20 > > > > command > > > > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable er= ror > > > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > > > da4: Removable Direct Access SPC-4 SCSI device > > > > da4: Serial Number somer serial numbers > > > > da4: 400.000MB/s transfers > > > > da4: 475000MB (972800000 512 byte sectors) > > > > da4: quirks=3D0x2 > > > > [...] > > > > > > > > Trying to mount via: # mount -t ext2fs /dev/da4p1 /mnt/image > > > > > > > > [...] > > > > (da4:umass-sim0:0:0:0): got CAM status 0x444 > > > > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > > > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > > > da4: s/n some serial numbers detached > > > > (da4:umass-sim0:0:0:0): Periph destroyed > > > > > > > > mount: /dev/da4p1: Device not configured > > > > =20 > > > > > > This has the classic hallmarks of a drive that loses its mind on > > > SYNCHRONIZE CACHE. Normally, we detect that automatically, but someti= mes =20 > > we =20 > > > don't. Let's see if this drive is suffering from that. These instruct= ions > > > are a bit long, but the shorter ones are harder to explain :). > > > > > > First, you'll need to find what this drive is. You'll need to use > > > "usbconfig -v" to find the drive. Redirect that to a file, then searc= h, =20 > > you =20 > > > should find something akin to > > > > > > ugen0.13: > > Technology Corp.)> at usbus0, cfg=3D0 md=3DHOST spd=3DSUPER (5.0Gbps)= pwr=3DON > > > (76mA) > > > ugen0.13.0: umass1: > > > > > > The first line might not match, and the numbers will be different. But > > > you'll need the vendor and product IDs from this drive. They are a few > > > lines later and look akin to the following: > > > ... > > > idVendor =3D 0x090c > > > idProduct =3D 0x1000 > > > ... =20 > > > > You'll find the required output as attachment, desinated usb_asolid.txt. > > > > The required identifications should be > > > > idVendor =3D 0x24a9 > > idProduct =3D 0x205a > > bcdDevice =3D 0x0110 > > > > =20 > > > > > > Now, remove the drive and type in the following (with your vendor and > > > product replacing mine): > > > > > > usbconfig add_dev_quirk_vplh 0x090c 0x1000 0x0000 > > > 0xffff UQ_MSC_NO_SYNC_CACHE =20 > > > > In my case in question it would be > > > > usbconfig add_dev_quirk_vplh 0x24a9 0x205a 0x0000 0xffff > > UQ_MSC_NO_SYNC_CACHE > > > > right? > > =20 > > > > > > This will add a quirk to the usb quirk table. You should see =20 > > NO_SYNC_CACHE =20 > > > show up in the da4 probe quirk report when you plug the drive back in. > > > > > > If that fixes it, please let me know. "Hang on close" or "Periph goes= =20 > > away =20 > > > on close" very often is due to this. umount will close the device. I = may > > > have additional questions for you to help me add a quirk or a heurist= ic =20 > > to =20 > > > the code... I'm not yet sure, though, of the correlation to big files= . It > > > may be something else, or it may be this. =20 > > > > Do not see required state change in output: > > > > [...] > > ugen1.5: at usbus1 > > umass0 on uhub6 > > umass0: on usbus1 > > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00= 10 > > 00 00 > > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > > command > > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > > =20 >=20 > I would have expected a quirk line for umass0: >=20 > [911991.296485] umass1 numa-domain 0 on uhub13 > [911991.299036] umass1: addr 12> on usbus0 > [911991.305703] umass1: SCSI over Bulk-Only; quirks =3D > 0x4000 >=20 > Is what I get. I don't see the SCSI over Bulk-Only line either in your > demsg. I wonder why. >=20 My crap device is at 1.5: ugen1.5: at usbus1, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr= =3DON (200mA) > I think your device is at 0.6, so something like the following (confirm > with usbconfig showing ugen0.4 as this device): >=20 > usbconfig -d ugen0.6 power_off > usbconfig -d ugne0.6 add_quirk UQ_MSC_NO_SYNC_CACHE > usbconfig -d ugen0.6 power_on #: sudo usbconfig -d ugen1.5 power_off #: sudo usbconfig -d ugen1.5 add_quirk UQ_MSC_NO_SYNC_CACHE #: sudo usbconfig -d ugen1.5 power_on which gives me: # dmesg ugen1.5: at usbus1 umass0 on uhub9 umass0: on usbus1 da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: Removable Direct Access SPC-2 SCSI device da4: Serial Number 25010993010046 da4: 40.000MB/s transfers da4: 475000MB (972800000 512 byte sectors) da4: quirks=3D0x2 umass0: at uhub9, port 2, addr 4 (disconnected) da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: s/n 25010993010046 detached (da4:umass-sim0:0:0:0): Periph destroyed umass0: detached umass0 on uhub9 umass0: on usbus1 da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: Removable Direct Access SPC-2 SCSI device da4: Serial Number 25010993010046 da4: 40.000MB/s transfers da4: 475000MB (972800000 512 byte sectors) da4: quirks=3D0x2 And with a 256GB expensive SAMSUNG USB Flash: ugen1.5: at usbus1 umass0 on uhub6 umass0: on usbus1 da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: Removable Direct Access SPC-4 SCSI device da4: Serial Number 0373220010001862 da4: 400.000MB/s transfers da4: 244752MB (501253132 512 byte sectors) da4: quirks=3D0x2 doing the simialr thing as you did: sudo usbconfig -d ugen1.5 power_off sudo usbconfig -d ugen1.5 add_quirk UQ_MSC_NO_SYNC_CACHE sudo usbconfig -d ugen1.5 power_on gives: (da4:umass-sim0:0:0:0): Periph destroyed umass0: detached umass0 on uhub6 umass0: on usbus1 da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 da4: Removable Direct Access SPC-4 SCSI device da4: Serial Number 0373220010001862 da4: 400.000MB/s transfers da4: 244752MB (501253132 512 byte sectors) da4: quirks=3D0x2 REMARK: I use a USB HUB, powered, might that induce some spooky actions? My= housing does have outdated USB 2 connectors on the front, it is hard for me to crawl undernea= th the (dusty) desk behind the housing and search for a free USB 3 port ... >=20 > is what I did to generate the umass line above (but with 0.13 instead of > 0.6). I wish there was a quirk for REPORT LUNS not being supported, but > that warning is harmless. We'll ignore the error and go on to the next > thing (I should fix the errors we're just going to ignore when they aren't > supported, but I digress). If you can build a kernel, adding USB_DEBUG to > it for the duration of testing would give us more information, including > the line that I have and that you don't (maybe I should make that > unconditional). >=20 >=20 > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > da4: Removable Direct Access SPC-4 SCSI device > > da4: Serial Number 25010993010046 > > da4: 400.000MB/s transfers > > da4: 475000MB (972800000 512 byte sectors) > > da4: quirks=3D0x2 > > ugen1.5: at usbus1 (disconnected) > > umass0: at uhub6, port 1, addr 4 (disconnected) > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > da4: s/n 25010993010046 detached > > (da4:umass-sim0:0:0:0): Periph destroyed > > umass0: detached > > ugen1.5: at usbus1 > > umass0 on uhub6 > > umass0: on usbus1 > > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00= 10 > > 00 00 > > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > > command > > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > da4: Removable Direct Access SPC-4 SCSI device > > da4: Serial Number 25010993010046 > > da4: 400.000MB/s transfers > > da4: 475000MB (972800000 512 byte sectors) > > da4: quirks=3D0x2Tryping to mount > > > > [...] > > > > Trying to mount /dev/da4p1 (which is the supposed ext4fs/ext2fs partiti= on > > on the USB > > flash device) results in: > > > > WARNING: R/W mount denied. Filesystem is not clean - run fsck > > > > and when trying to solve the problem via > > > > [...] > > # /compat/linux/sbin/fsck.ext4 /dev/da4p1 > > e2fsck 1.46.5 (30-Dec-2021) > > /compat/linux/sbin/fsck.ext4: No such file or directory while trying to > > open /dev/da4p1 > > Possibly non-existent device? > > > > and on console > > =20 >=20 > the following are the only new one? maybe I missed one line with "umass0: detached", see above, the new lines I= posted, there is one more line ... >=20 >=20 > > (da4:umass-sim0:0:0:0): got CAM status 0x444 > > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > da4: s/n 25010993010046 detached > > (da4:umass-sim0:0:0:0): Periph destroyed > > > > > > I think this special "low cost" device did not only lost its mind, it l= ost > > its head > > also. > > =20 >=20 > Yes. I kinda want to swap you for this: you send it to me and I'll send y= ou > one of my happy devices :) >=20 > Warner I would do that, if I could, but I would raise a "state incident" ;-) I might have another one, still wrapped in. But with reference to my SAMSUN= G Flash drive, see above, and not willing disabling SYNCACHE, isn't it more likely to be some = issue with my setup/hardware? >=20 >=20 > > Regards, > > > > Oliver > > > > p.s. One note: > > > > # gpart show -l da4 =20 > > =3D> 40 972799920 da4 GPT (464G) =20 > > 40 972799920 1 (null) (464G) > > > > The device in question does have a GPT partition layout. I guess it > > doesn't matter here, > > but I'll add it anyway for the record. > > =20 > > > > > > Warner > > > > > > [...] =20 > > > > > > > > [...] > > > > # /compat/linux/sbin/fsck.ext4 /dev/da4p1 > > > > e2fsck 1.46.5 (30-Dec-2021) > > > > SINA was not cleanly unmounted, check forced. > > > > Pass 1: Checking inodes, blocks, and sizes > > > > Pass 2: Checking directory structure > > > > Pass 3: Checking directory connectivity > > > > Pass 4: Checking reference counts > > > > Pass 5: Checking group summary information > > > > Error writing file system info: Invalid argument > > > > > > > > XXXX: ***** FILE SYSTEM WAS MODIFIED ***** > > > > > > > > [...] > > > > > > > > detaching and attaching to another USB slot on the same (external) = HUB: > > > > > > > > [...] > > > > ugen1.5: at usbus1 > > > > umass0 on uhub6 > > > > umass0: on usbus1 > > > > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 0= 0 =20 > > 00 10 =20 > > > > 00 00 > > > > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > > > > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > > > > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 =20 > > (Invalid =20 > > > > command > > > > operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable er= ror > > > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > > > da4: Removable Direct Access SPC-4 SCSI device > > > > da4: Serial Number some serial numbers > > > > da4: 400.000MB/s transfers > > > > da4: 475000MB (972800000 512 byte sectors) > > > > da4: quirks=3D0x2 > > > > linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fallback fd=3D3, =20 > > cmd=3D0x127c =20 > > > > ('\^R',124) is > > > > not implemented linux: jid 0 pid 5087 (fsck.ext4): linux_ioctl_fall= back > > > > fd=3D3, cmd=3D0x125e > > > > ('\^R',94) is not implemented (da4:umass-sim0:0:0:0): got CAM statu= s =20 > > 0x444 =20 > > > > (da4:umass-sim0:0:0:0): fatal error, failed to attach to device > > > > da4 at umass-sim0 bus 0 scbus11 target 0 lun 0 > > > > da4: s/n some serial numbers detached > > > > (da4:umass-sim0:0:0:0): Periph destroyed > > > > > > > > [...] > > > > > > > > I can not even mount the device on CURRENT (FreeBSD 16.0-CURRENT #1 > > > > master-n282217-34d66b0c96d5: Fri Nov 28 05:15:56 CET 2025 amd64). > > > > > > > > Package used for linux operation: emulators/linux-rl9 > > > > =20 > > > > =20 --=20 A FreeBSD user --Sig_/CZs8u8qKZNUFV84ak0RVn5. Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaSs9fAAKCRCxzvs8Oqok r3I+AP4gsJXsaZ143mig3z7dfEevxIsojAHe6t7SK87bxD8h+AD/aNJvnf1k8Nrd GKEAtSxhZAeXtYoYOSejtTQ9l7kICAY= =nYHv -----END PGP SIGNATURE----- --Sig_/CZs8u8qKZNUFV84ak0RVn5.-- From nobody Sun Nov 30 12:57:22 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 4dK6WR3GNfz6JPn9; Sun, 30 Nov 2025 12:57:23 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 "freefall.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dK6WR2bwKz40b6; Sun, 30 Nov 2025 12:57:23 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764507443; 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; bh=XWWsQyF8vALoDxvIFFNeBKB1Au9Ye/teB7UmbAOjUyE=; b=d8BdlpU5leQdEczaZG0rJfzxfmBKmgZUHAdDSRwTrh4xZ0wmCsSly/d9x5ZAFYAZsxESR1 9Fk1KGaXhDgqucTccx5O50VAbLRrVLW3BPgSfTEp4Xbkbe5IaF1B9+/EW4wHL0Pz7mW/Nl Gmc3bscVyi0UvDeqZ4egtPXxgG6mCSyRikJkjoJrT6bNFEdeRWM/NEFgqSFSSCQ79c9IUU 5nxNoFTkxRmfkFp40r/qGLayqd19kn9KCGRJnRMT15zvWInlWdscyg+o7Gi/bgluL8uAGO KMd+GolHX/aZhKyusBTtHVPuvYhEiBm/m3Ht7H+RBlVH5j0vUQWkJtwr+Uu1iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764507443; 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; bh=XWWsQyF8vALoDxvIFFNeBKB1Au9Ye/teB7UmbAOjUyE=; b=hXQrYDrS10ErpCtkomAP+CQzdxZQ5q10zoHL8JuyLr6Z4JjlH2eKouvA5sww2ew8fP23es LRxSNL57CxUjEda8mpC5uZFZZnaP94WwmvA9z/XESLCDRza1xxcWP2oztfsqm+Jp2WU385 veDYScG8tQQ3Xw+ms8KcAO/VeKo9EjVggifjHiHziqNI6oltLOdpiRe3LcVQ4ouYKNDQ8k 2bTcT16UXhsfkd00BDmXo9CEzckq5wYKi4haK2UrIvCifgHgjgbtVsK8xf++xD4Hficnac 6C6qSyoj4EJgjkl84VSMmk+7GaCvWulxJ5W+i9lGby0V5r2UsR1MbmxOS/3l8g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764507443; a=rsa-sha256; cv=none; b=luWOvRcD2VyFFz2SvFPHBRoqzBiGuAtQt44bgPkyTWBJRTzPrzRBhGQCWOBFzmesAKIzKg YoWvwDhy1xyRnmkg/pfFRQ727OM012I3ZUxI9LbbwPzR3/Eq7fnQtjjdJekxBSRn8IjnOf lWrKoGPq15J3BuUWrFq3krd5TTxaH4vEDcT5kBg1lIThNCuxqYwLBVahn7uPSUftD8H3J5 Apm1QJkhjp9W7Q5TfsaSwyVMZKf+PHBEvI8aw2vDsF5Gmo5QHJUOPgR1i0aX5BQFl8PW87 QttkfgQiTZ2g/B0tx7sR3mQ/+6RBtmt4d/ZlQIER62ivPKVa4I7mGYuSej824Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: by freefall.freebsd.org (Postfix, from userid 1472) id 38B05B6CE; Sun, 30 Nov 2025 12:57:23 +0000 (-00) Date: Sun, 30 Nov 2025 12:57:22 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Status Report - Third Quarter 2025 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit FreeBSD Status Report Third Quarter 2025 Here is the third 2025 status report, with 36 entries. As usual, reports publication is slow due to some important reports arriving late. We are sorry about that, but most of us are volunteers and we do our best. Luckily, it seems that the number of volunteers is about to increase: last quarter I have seen much interest among new community members in getting involved in the FreeBSD Project. This will surely improve the efficiency of the whole development, including status reporting. Many new recruits approach us with the same question: "How do I start?". This is not the place to give an answer to this question, but actually a guide has been written precisely to reply to it. You can find it here. Moreover, it is always good to remember that using FreeBSD, as much as possible, helps a lot: use it as your daily driver, run your webservers on it, install it on your virtual machines, support it when you contribute to existing software! And if you find bugs, do not forget to report them. Have a nice read! Lorenzo Salvadore, on behalf of the Status Team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2025-07-2025-09/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Ports Collection • Projects □ Framework Laptop support □ Infrastructure Modernization □ Alpha-Omega Beach Cleaning project □ STA Work Package C: CI/CD Automation □ Support for installing pkgbase systems □ Sylve — A Unified System Management Platform for FreeBSD □ FreeBSD Git Weekly □ July 2025 FreeBSD Hackathon in Berlin, Germany • Userland □ ACPI Lua Bindings □ Geomman Release □ Sockstat UI Improvements □ Process Credentials' Groups-Related Changes in FreeBSD 15 □ The Gallant Console Font got Supercharged • Kernel □ Audio Stack Improvements □ DRM drivers □ DRM Drivers Slowdowns and Freezes Fixes □ LinuxKPI 802.11 and Native Wireless Update □ mac_do(4) and mdo(1) Improvements □ Suspend/Resume Improvement □ USB Kernel Debugging Improvements • Architectures □ FreeBSD Driver Development for BananaPi-R64 • Cloud □ Improvements for nuageinit • Documentation □ Documentation Engineering Team □ The FreeBSD Russian Documentation Project • Ports □ A bhyve management GUI written in Freepascal/Lazarus □ Container orchestration: Overlord, Director, AppJail and cloud-init □ Improve libvirt support for bhyve hypervisor □ Improve OpenJDK on FreeBSD □ KDE on FreeBSD □ GCC on FreeBSD □ Valgrind: preparing for 15.0-RELEASE □ A new Wi-Fi management utility: wutil ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. Completed Items Core completed the following items: • EuroBSDCon core session □ dch, glebius, hrs, rene were present at the conference. □ dch had a talk with title "Core Team: Personal Perspective" • Removing links to X/Twitter from the project website. □ Core received a question if it is OK to remove links to X/Twitter from the project website. □ As the handle is not being used, core thinks this is fine. □ The Project still needs to control the handle to avoid abuse by others. □ The link can be re-added if someone in the project or Foundation can use those SNS accounts well. • Privacy-friendly web analytics, proposed by the Foundation. □ An idea is to compare traffic flows between freebsd.org and freebsdfoundation.org □ Collaborated with doceng and deployed. • Core and the FreeBSD Foundation were working on publishing the 2025 edition of the Community survey result. Work in Progress Core is currently working on the following items: • Core is creating a working group to restructure doceng. • Committer mentorship guideline/rule □ Brought up by inquirers from the developers. □ Core idendified there are some existing documentations but should ask doceng/portmgr/srcmgr for more input. • Core election and term changes □ From the feedback of the community, the preferred way is staggered core terms. □ One idea is to rate half of core every year instead of rotating possibly. all of core every two years, so that in-progress work and experience do not get lost. □ Some developers have strong ideas about this (like rotating a third of core each year instead of all of core every two years) and would like to be involved. □ We need to have the bylaws changed for this, the standard is high. □ There are suggestions from the community for we just change the bylaws as core does not legally represent anybody. Is that really a good idea? □ This discussed at core session at BSDCan developer summit 2025. □ Core is continuously working on this toward to setup staggered core terms. • Project continuity □ Brought up by an inquriy from a developer □ We need (updated) documentation on how to rebuild the critical systems to ensure business continuity of the FreeBSD Project. This encompasses three aspects: □ Our own project business continuity (loss of key personnel or infrastructure) □ Replication for end consumers of FreeBSD □ How does our release engineering work, and which of the various teams are impacted. □ Currently too much knowledge depends on tribal memory, need to collect, sort and documented. □ An artifact of the STA work is that release documentation is written (next to the releng article in doc repository). Some corner cases are currently missing. • Committer GECOS fields and pseudonyms □ A question came from a developer about whether pseudonyms can be used as committer names. □ There is a higher concern about how to deal with any copyright issues. □ Core however does not feel that using pseudonyms is endorsed as it makes paperwork and restoring cluster access more difficult, and suggests mentioning the advantages of using real names. □ Another way pseudonyms could cause problems is when the identity is shared, e.g. in case of a vendor commit bit, who will be the spokesperson? • AI policy □ The Core Team is in the process of drafting a policy on using AI and LLMs. □ For this effort, it also plans to consult with other groups, such as the Foundation’s legal counsel and people in the Linux and other open source communities who are working on related topics. □ There are various questions about copyright, guaranteeing code provenance, best practices and "common sense" by both developers and external contributors, and what can and cannot be done with AI (assisted) tools. □ There have been many follow-up discussions after BSDCan and EuroBSDCon, and core is organizing and summarizing them. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://freebsdfoundation.org/ Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/ Donate URL: https://freebsdfoundation.org/donate/ Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/ FreeBSD Journal URL: https://freebsdfoundation.org/journal/ Foundation Events URL: https://freebsdfoundation.org/our-work/events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit dedicated to advancing FreeBSD through both technical and non-technical support. Funded entirely by donations, the Foundation supports software development, infrastructure, security, and collaboration efforts; organizes events and developer summits; provides educational resources; and represents the FreeBSD Project in legal matters. OS Improvements Throughout the quarter, there were 451 src, 71 ports, and 25 doc commits sponsored by the FreeBSD Foundation. Refer to the following report entries describing much of that committed development work: • Suspend/Resume Improvements • LinuxKPI 802.11 and Native Wireless Update • Audio Stack Improvements • Improve OpenJDK on FreeBSD • Sylve — A Unified System Management Platform for FreeBSD • Support for Installing pkgbase Systems • DRM drivers • Alpha-Omega Beach Cleaning Project • Improve libvirt Support for bhyve Hypervisor • STA Work Package C: CI/CD Automation • USB Kernel Debugging Improvements • DRM Drivers Slowdowns and Freezes Fixes • Process Credentials' Groups-Related Changes in FreeBSD 15 Other highlights include: • Improved virtual memory scalability, allowing multiple processes to load shared libraries in parallel. • Greater UFS reliability on very large filesystems (with more than 2 billion inodes). • Support for systems with over 4 TB of RAM, including a reworked Kernel Virtual Address (KVA) layout tailored for the 57-bit address space (LA57) architecture. • Kqueue inheritance across fork(). • A new safeguard (noshutdown) to help prevent accidental system shutdown. • Simplified and more reliable filesystem rename operations. • A fix for amd64 pmap panics under low-memory conditions. • Numerous fixes for race conditions in timeout handling. • A new EXTERROR(9) interface, standardizing how external applications can report detailed error information. The Foundation also continued to support two major initiatives: the Laptop Support and Usability project (in collaboration with Quantum Leap Research) and an infrastructure modernization project commissioned by the Sovereign Tech Agency. For background on both efforts, see the 2025Q1 quarterly status report. FreeBSD, under the management of the Foundation, participated in its 21st consecutive Google Summer of Code (GSoC) program. All twelve projects were successfully completed. Four of those GSoC participants contributed report entries: • ACPI Lua Bindings • Sockstat UI Improvements • Geomman Release • mac_do(4) and mdo(1) Improvements Advocacy Advocacy work in the 3rd quarter of 2025 included representing FreeBSD at open source events, producing more technical tutorials and working on the upcoming November 2025 FreeBSD Vendor Summit. Take a look at just a few of the ways the Foundation helped advocate for FreeBSD in Q3 of 2025: • Sponsored and attended EuroBSDcon 2025, held in Zagreb, Croatia; September 25-28, 2025. • Members of the Foundation team presented at the Open Source Summit, Europe, August 25-27, 2025, Amsterdam, Netherlands. • Planning continued for the November 2025 FreeBSD Vendor Summit, taking place November 6-7, 2025 in San Jose, CA. Registration is open and the schedule is available. • Published the following blogs and videos to help to inform and educate the community: □ How To Install and Configure the Galene Video Meeting Server □ An Introduction to FreeBSD’s Periodic System □ BSDCan 2025 trip reports: ☆ Mark Johnston ☆ Chuck Tuffli □ From Minecraft to Markets: Java Hiding in Plain Sight □ FreeBSD Jails are Simple and Easy • Published the June/July 2025 and August 2025 FreeBSD Foundation Newsletters. • Released the April/May/June 2025 issue of the FreeBSD Journal with HTML versions of the articles. Continuous Integration and Workflow Improvement The Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and test infrastructure. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://freebsdfoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 15.0-RELEASE schedule URL: https://www.freebsd.org/releases/15.0R/schedule/ FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The Team managed the first half of the 15.0-RELEASE cycle, aiming for the official RELEASE build and announcement in December. Of note, this has involved a significant amount of pkgbase-related work landing. The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/14, and stable/13 branches. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/# ports-contributing Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: Tobias C. Berner Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. During the last quarter, we welcomed Älven (alven@) and Tiago Gashiba (tiga@) as new ports committers, and said goodbye to six committers. We also promoted Dan Langille (dvl@) as a full portmgr member after successfully being on the lurker program. According to INDEX, there are currently 37,163 (up from 36,605) ports in the Ports Collection. There are currently about 3,428 (up from 3,330) open ports PRs, of which 821 are unassigned. The last quarter saw 8,738 (down from 10,924) commits by 156 (down from 157) committers on the main branch and 898 (up from 770) commits by 61 (up from 56) committers on the 2025Q3 branch. The most active committers to main were: • 2348 sunpoet@FreeBSD.org • 574 yuri@FreeBSD.org • 409 vvd@FreeBSD.org • 406 tagattie@FreeBSD.org • 348 bofh@FreeBSD.org • 223 jbeich@FreeBSD.org • 161 fluffy@FreeBSD.org • 153 eduardo@FreeBSD.org • 147 alven@FreeBSD.org • 143 arrowd@FreeBSD.org A lot has happened in the ports tree in the last three months, an excerpt of the major software upgrades are: • pkg 2.3.1 • New USES: zig • Default version of Lazarus switched to 4.2 (non-devel, non-aarch64) • Default version of Perl switched to 5.42 • Chromium 140.0.7339.207 • Electron 37 and 38 added • Firefox 143.0.3 • Firefox-esr 140.3.1 • KDE Applications 25.08.1 • KDE Frameworks 6.18.0 • KDE Plasma 6.4.5 • Ruby 3.4.6 • Rust 1.89.0 • SDL 3.2.22 During the last quarter, pkgmgr@ ran 12 exp-runs to test source code changes and various ports upgrades. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Framework Laptop support Links: Framework Laptop page on FreeBSD Wiki URL: https://wiki.freebsd.org/Laptops/Framework_Laptop/ Guide on installing and using FreeBSD on Framework systems URL: https://github.com/FrameworkComputer/freebsd-on-framework Tracking ticket: Framework Laptop: Feature support, bugs and improvements URL: https://bugs.freebsd.org/262152 Contact: Daniel Schaefer Contact: Li-Wen Hsu Contact: ShengYi Hong Framework Computer Inc. is very supportive of the FreeBSD project in many ways, including providing engineering samples to the Foundation for testing and working on compatibility. The Foundation continues to work on improving overall laptop support, and Framework laptops are one of the target platforms for the Laptop Support and Usability Project. In the 2nd and 3rd quarter of 2025, there were two hackathons held in Framework’s Taipei office to test FreeBSD on the products newly released and in development. In April, we continued testing Framework Laptop 12 and Framework Desktop for the support of the in-development 15.0, including the ethernet support, serial console access, etc. In September, we worked on testing Framework Laptop 16 AMD Ryzen AI 300 Series, including the NVIDIA Graphics Module. ShengYi fixed the sound support for this model. Daniel has fixed fwupd on FreeBSD (#9220, #9221, #9223) and revived the FreeBSD CI. This work is included in the fwupd 2.0.16 release. Sponsor: The FreeBSD Foundation for Li-Wen and ShengYi’s work Sponsor: Framework Computer Inc for Daniel’s work, hardware and space support ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Infrastructure Modernization Contact: Ed Maste Contact: Alice Sowerby The project started in Q3 of 2024 and was commissioned by the Sovereign Tech Agency with a budget of $745,000, to be spent until the end of 2025. The main goals are to improve security tools for the base system, ports, and packages, update the project’s infrastructure to speed up development, enhance build security, and make it easier for new developers to get started. For more detailed information and updates, please visit the new project information repo. Q3 update All five work packages are in progress and will run until the end of December 2025, at which time the project will close. Work Package A: Technical Debt Reduction This work package is complete as of September 2025. The project successfully ran alongside the setting up of the FreeBSD Project’s Source Management team as they created and embedded their new processes to make bug management easier and more sustainable. The bug backlog dashboard they commissioned remains available to help make the backlog easier to understand. In August, we held a panel discussion at Open Source Summit Europe to share this work with a wider audience. Two members of the Foundation project staff (Alice Sowerby and Moin Rahman) were on the panel along with two representatives from Bitergia who delivered the GrimoireLab implementation for this project. (Members of the FreeBSD Project Source Management team were not available to attend.) The Foundation will continue to check in with the Source Management team regularly until at least the end of 2025 to ensure that we understand the value of the project going forward. The scope was co-created with srcmgr@. Work items are as follows: • Create a dashboard for the Source Management team to get a clearer picture of the bug backlog, and how effectively it is being managed (e.g. Time to First Attention for new bugs). □ Output: https://grimoire.freebsd.org/ • Upgrade Bugzilla to a supported release to improve security and benefit from new functionality. □ Output: https://wiki.freebsd.org/Bugzilla/Roadmap • Create a method for applying patches automatically. □ Output: https://github.com/linimon/patchQA • Creating upstream documentation for running GrimoireLab (bug dashboard) on FreeBSD. □ Output: https://github.com/chaoss/grimoirelab/blob/main/FreeBSD.md Work Package B: Zero Trust Builds This work package intends to improve tooling and processes to support Zero Trust Builds of FreeBSD by extending the current components to enable the project to build release artifacts (package sets, ISO images, etc.) without requiring any special privilege. The detailed scope was co-created with core@, srcmgr@, secteam@. Work items are as follows: • Must □ No-root for all source release build cases/artifacts (complete) □ Src artifacts to build reproducibly (in progress) □ Formalize and document make world and release.sh (in review) • Should □ Remove privilege from orchestration tooling (not started) □ Move build scripts into the public repository (in progress) □ Address dependencies (in progress) • Could □ Environment Standardization (in progress) □ Ports to build reproducibly (in progress) □ CI to verify reproducibility (in progress) □ Documentation to allow 3rd parties to confirm reproducibility (not started) Work Package C: CI/CD Automation This work package intends to improve CI/CD automation to streamline software delivery and operations for new and existing software by modernizing and securitizing the existing CI/CD system and extending it to cover the third party packages in the FreeBSD Ports Collection. The detailed scope was co-created with core@, srcmgr@, portmgr@, doceng@ * Must Improve quality of incoming commits (completed) Pre-merge CI (completed) Environment Metadata (in progress) Extend CI to the Ports tree (in progress) CI Threat Model (in progress) CI Management Process (in progress) Documentation (not started) * Should 3rd-party Interoperability (in progress) Automated analysis in tests (in progress) Test Case Management (in progress) * Could ** Granular Debugging (in progress) Work Package D: Ports and Packages security improvements This work package intends to modernize and extend security controls in the FreeBSD Ports and Package Collection by: Migrating from our VuXML Vulnerability Database to OSV or similar contemporary format; developing a package audit backend and server to reliably fetch vulnerability data from global agency databases in any format (JSON - NIST) and produce insight and; improving CI tooling for FreeBSD Ports. The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@ • Must □ New Database Format (in progress) □ Set up 2+ Database Instances (not started) □ Migrate Data from old to new database (in progress) □ Add support for new format in pkg(8) (in progress) □ Upstream engagement (in progress) □ SBOM on demand (not started) □ Document how to set up build and test targets (not started) □ Integrate 3rd party test targets (not started) □ Continuous Testing (not started) • Could □ Make CI artifacts available (not started) Work Package E: SBOM improvements This work package intends to improve existing, and implement new, tooling and processes for FreeBSD Software Bill of Materials (SBOM) by implementing: tooling to roll up the individual provenance data/markers from across the tree into a higher-level view; developing tooling to parse/review/inspect the FreeBSD source tree and produce a comprehensive/holistic report to act as a SBOM for the full software stack and; extending pkg to enable this capability for software installed from ports/packages. The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@, releng@ • Must □ Evaluate projects/solutions available in the wider ecosystem (in progress) □ Propose the target solution for SBOM (in progress) □ Produce an SBOM in CI (e.g. weekly builds) (in progress) □ Produce an SBOM as an artifact as part of the release process (in progress) □ SBOM artifact on demand (in progress) □ Roll up existing data (in progress) □ Record and explain decisions made (in progress) • Could □ Engage with other similar projects (in progress) Commissioning body: Sovereign Tech Agency ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Alpha-Omega Beach Cleaning project Links: Alpha-Omega — Linux Foundation Project URL: https://alpha-omega.dev Alpha-Omega on GitHub URL: https://github.com/ossf/alpha-omega FreeBSD Foundation URL: https://freebsdfoundation.org Project repository from the FreeBSD Foundation URL: https://github.com/FreeBSDFoundation/alpha-omega-beach-cleaning Contact: Pierre Pronchery Alpha-Omega’s mission is to catalyze sustainable security improvements to critical open source projects and ecosystems. After a successful project with the FreeBSD Foundation in 2024 — auditing the bhyve hypervisor and the Capsicum sandboxing framework — Alpha-Omega has selected FreeBSD again, for the Alpha Omega Beach Cleaning project this time. This new grant consists in generally improving the security and maintenance of third-party software within the FreeBSD base system. The FreeBSD Foundation received the grant and is managing and executing the project. The list of tasks has been determined as follows: • Inventory of dependencies • Security risk assessments • Propose list of priorities • Plan the respective actions • Formalize code owners • Integrate review methodologies • Plan execution & coordination • Final report The first deliverables have been issued on the dedicated GitHub repository: • Machine-readable database • List of dependencies • Security risk assessments Help is welcome to complete the information collected, and to improve on any other aspect of the project! Finally, monthly reporting is submitted and available on GitHub. Sponsor: Alpha-Omega, The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ STA Work Package C: CI/CD Automation Contact: Siva Mahadevan In this quarter, as part of the infrastructure modernization work commissioned by the Sovereign Tech Agency (STA), I have been working on the in-tree CI Makefile targets. I also worked on bringing our CI test reports to a clean state on our tier-1 architectures (amd64 and aarch64). This report is a supplement to the overall STA status report and will describe the work done in more detail. tests/ci improvements The tests/ci subdirectory in the src tree was introduced in commit: Add preliminary in-tree CI infrastructure for developers by Moin Rahman and aims to provide an easy way for developers to replicate the CI testing run by our Jenkins cluster. In this quarter, the following improvements were made by the team: New functionality: • tests/ci: run ci-full kyua tests in parallel • tests/ci: Add KYUA_TEST_FILTERS to allow user to select specific tests • tests/ci: Add CIENV variable Bug fixes: • tests/ci: Use suitable variable for qemu-user-static existence check • tests/ci: fix race condition in bhyveload boot • tests/ci: fix missing /usr/local/{sbin,bin} in freebsdci rc PATH • tests/ci: Fix missing qemu devices • tests/ci: Fix race condition with ci-extractmeta • tests/ci: Fix wrong chflags target path in 'beforeclean' target • tests/ci: Use QEMU blockdev declaration for all platforms • tests/ci: Fix unescaped kld_list var in rc.conf With these changes, a developer can run CI with these example commands as root: # Fully parallel CI: make ci # Single-threaded CI make PARALLEL_JOBS=1 ci # Single-threaded CI, running a subset of the tests as described in kyua-test(1) make PARALLEL_JOBS=1 KYUA_TEST_FILTERS='/path/to/testcase /path/to/another:testname1' ci # Run smoke (boot) tests make CITYPE=smoke ci Test case management Tinderbox has been reporting that our supported platforms are failing in CI since a run from the last quarter. As the backlog grows larger, it becomes harder for users and developers to notice a new failure and pin it to a particular commit. To complement the tests/ci CI/CD automation improvements, along with Bricoler to help with more granular investigations, I worked on cleaning up the failing test backlog on tier-1 architectures. The following patches and bug reports were submitted as a result of this (still ongoing) work: New bug reports filed to track failing or flaky tests: • PR 288991: sys/netinet/output:output_raw_flowid_mpath_success • PR 289096: lib/libexecinfo/sigtramp_test:test_backtrace_sigtramp • PR 289165: usr.bin/limits/limits_test:cputime_soft_flag • PR 289240: sys/netlink/netlink_socket:overflow • PR 289239: sys/netpfil/pf/sctp:pfsync • PR 289236: sys/kern/exterr_test:gettext_extended • PR 289382: sys/netinet6/lpm6:lpm6_test1_success • PR 289628: sys/netpfil/pf/nat:endpoint_independent_pass • PR 289630: libexec/rc/rc_subr_test:wait_for_pids_progress • PR 289237: sys/fs/fusefs/last_local_modify:main • PR 289084: lib/libc/string/memcmp_test:{diff,neq} • PR 289477: sys/netpfil/pf/ route_to:prefer_ipv6_nexthop_mixed_af_random_table_ipv4 • PR 289299: sys/netpfil/pf/rules_counter:keepcounters • PR 289684: sys/netlink/test_snl:snl_parse_errmsg_capped • PR 289146: sbin/ipfw/test_add_rule.py:TestAddRule::test_add_action Unskip tests that are wrongly skipped in CI: • tests/sys/netpfil: unskip tests that no longer need to be skipped • tests/ci: Add missing kmods and pkgs to unskip tests Test case metadata fixes: • fix parallel execution of swapon tests • cap_dns/tests/dns_test: mark tests as needing network access • pfctl tests: use require.kmods instead of manual check for pf • cap_net/net_test: require 'allow_network_access' • tests/mac_portacl: enable is_exclusive for now • tests/sys/mqueue: use require.kmods property instead of ad-hoc checks • tests/sys/netlink: use require.kmods property instead of ad-hoc checks • tests/sys/opencrypto: use require.kmods property instead of ad-hoc checks • tests/sys/aio: use require.kmods property instead of ad-hoc checks • tests/pf/ioctl: use require.kmods property instead of ad-hoc checks • tests/sys/netmap: use require.kmods property instead of ad-hoc checks • tests/sndstat: use require.kmods property instead of ad-hoc checks • tests/socket_accf: use require.kmods property instead of ad-hoc checks • tests/sys/net: use require.kmods property instead of ad-hoc checks • tests/sys/netinet: use require.kmods property instead of ad-hoc checks • tests/vmm_cred_jail: use require.kmods property instead of ad-hoc checks mark tests as "expected fail" (xfail), currently WIP: • atf_pytest: fix xfail detection from pytest report Tooling (WIP) To catch errors more quickly, instead of relying on Jenkins to update the test report, I ran local CI multiple times daily. To help with this, I worked on some tooling to speed up the testing/debugging cycles. I am maintaining the following (currently uncommitted) tools: • parallel CI runner built on top of tests/ci • (VERY WIP) automated CI bug report/triage system Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Support for installing pkgbase systems Contact: Isaac Freund The FreeBSD 15.0 snapshot installation images (disc1.iso, dvd1.iso) now include offline pkgbase packages rather than traditional distribution tarballs. This makes it possible to install a pkgbase system without an internet connection. Patches to build FreeBSD 15.0 VM and cloud images as pkgbase systems are in review and should land soon. Switching the VM and cloud images over to pkgbase is the last major step needed to make pkgbase the default installation path for FreeBSD 15.0. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Sylve — A Unified System Management Platform for FreeBSD Links: GitHub URL: https://github.com/AlchemillaHQ/Sylve CI URL: https://sylve-ci.alchemilla.io Discord URL: https://discord.gg/bJB826JvXK Contact: Hayzam Sherif Sylve is a modern, unified system management platform for FreeBSD, inspired by Proxmox. We aim to provide an integrated web interface for managing virtual machines (via Bhyve), Jails, ZFS storage, networking, and firewalling. The backend is implemented in Go, while the frontend uses SvelteKit with Tailwind CSS and ShadCN UI components. The project emphasizes a minimal system footprint, currently requiring only sysutils/smartmontools, sysutils/tmux, libvirt, samba419, swtpm as runtime dependencies. Q3 Progress Highlights Clustering Sylve now supports simple clustering with a single-pane-of-glass (SPOG) experience. This multi-master design, built on top of hashicorp/raft and SQLite, allows users to manage multiple nodes from a single interface. Networking • Network Objects: Subnets, hosts, and MACs are now treated as first-class objects. Users can create and reuse them across VMs, Jails, and switches. • Manual Switches: Existing FreeBSD bridges can now be imported into Sylve and managed as switches. Storage • A new file explorer has been introduced for managing each node’s local filesystem (copy, cut, delete, etc.). • ZFS pools now feature extensive health monitoring, including support for special vdevs (cache, log, etc.). • Major performance improvements to ZFS dataset viewing and editing. • Ability to flash images to ZFS zvols directly from the UI. • Samba integration: Users can now create Samba shares. A comprehensive audit log has been added to track file share activity. Authentication • Ability to create and manage users directly in the UI, including Samba users. • Groups can now also be created and managed from the UI. Virtual Machines • Full VM editing is now supported (storage, network, PCI devices, etc.). • TPM support (via swtpm) is available in both UI and API, this feature is currently experimental. • Support for reusing existing raw disks. • Added Wake-on-LAN functionality for VMs. Jails • Full support for thick jails (creation, editing, viewing). • Resource limiting for CPU and RAM has been implemented. • Networking for Jails supports both inherited configurations and switch-based (manual/standard) setups. Roadmap Update Due to community demand, Q3 focused on clustering instead of firewalling and network services. The following items have been pushed to Q4: • Firewall rules configuration. • DHCP support. • WireGuard VPN integration. The current roadmap is to complete clustering with external storage backup support (e.g., S3) before returning to networking services. Contributions, testing, and feedback are very welcome. If you are interested in contributing, consider helping with: • UI testing and accessibility feedback. • Bug reports and feature requests via GitHub. Sponsor: FreeBSD Foundation and Alchemilla (development and infrastructure support) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Git Weekly Links: FreeBSD Git Weekly URL: https://freebsd-git-weekly.tarsnap.net/ Contact: Graham Percival These are weekly lists of commits to the FreeBSD source tree, split into categories such as "documentation", "hardware support", "testing", and "kernel". Our goal is to make it easier for developers and users to keep track of changes in FreeBSD that are relevant to them, without needing to subscribe to the dev-commits-src-main mailing list and look at every single commit which lands in their mailbox. In the future, these reports might include summaries or additional information, but for now our focus is figuring out what type of classification will be most useful to the FreeBSD community. These weekly reports began on 2025-09-01. Sponsor: Tarsnap Backup Inc. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ July 2025 FreeBSD Hackathon in Berlin, Germany Links: Event page URL: https://wiki.freebsd.org/Hackathon/202507 Date: July Saturday 12th and Sunday 13th 2025 Location: Chaos Computer Club Berlin We had been invited to hold our two day Hackathon in the halls of the Chaos Computer Club Berlin. The full report can be found here. The approximately 30 participants hacked on the following projects: • Local Chatbot RAG with FreeBSD Knowledge • Cross compiling FreeBSD on macOS • Importing OpenSSL 3.5 • The netlinkification of PF • Injecting host executable into jails • Updating OpenSearch ports • Ambushing Mark Phillips with a Microphone • Patching rsync to handle extattr • Checking LICENSE files against SPDX templates • TCP/UDP checksum offloading for bhyve • Native FreeBSD containers with Podman • and more. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ACPI Lua Bindings Links: GitHub URL: https://www.github.com/kpowkitty/freebsd-src PR: libsa: Add isprint() URL: https://www.github.com/freebsd/freebsd-src/pull/ 1740 PR: loader: Move ACPI RSDP detection URL: https://www.github.com/freebsd/freebsd-src/pull/1843 PR: efi: Create libacpi URL: https://www.github.com/freebsd/freebsd-src/pull/1818 PR: liblua: ACPICA Lua bindings URL: https://www.github.com/freebsd/freebsd-src/pull/1819 Contact: Kayla Powell (AKA Kat) Mentor: Warner Losh Introduction For Google Summer of Code 2025, I have been working on a project under Warner Losh for ACPI Lua Bindings. ACPI (Advanced Power and Configuration Interface) is an interface for managing power in the OS, rather than in the BIOS. The goal is to expose ACPI to Lua in the loader for amd64 platforms, with future arm64 support. Outcomes • Lua is a much simpler, higher level scripting language that enables faster development. • It reduces ACPI-related guesswork in the bootloader. • It allows users to query and manipulate ACPI data before the kernel is entered, giving them control over loader-time configuration. Remarks If there are any specialized use cases for ACPI in the loader that my interface does not aid in, please reach out to me, and I will see what I can do. For now, this is the interface that I will be committing to the tree for GSoC, so while any extra work will have to come afterwards, I am interested in it (and encourage it). Current status • Completed: □ ACPICA initialized in loader for amd64 ☆ OsdMemory.c ☆ osunixxf.c ☆ AcpiInitializeSubsystem ☆ AcpiInitializeTables ☆ AcpiEnableSubsystem (in reduced hardware mode, with events enabled) ☆ AcpiLoadTables ☆ AcpiWalkNamespace ☆ AcpiEvaluateObject ☆ AcpiAttachData ☆ AcpiGetData ☆ AcpiDetachData □ Lua bindings ☆ lacpi_walk.c ○ Users can walk and read nodes on the namespace ☆ lacpi_object.c ○ Users can evaluate objects ☆ lacpi_data.c ○ Users can attach, get, and detach data from nodes ☆ Man Page • Future plans: □ lacpi_walk.c (V2) ☆ Namespace printout format □ lacpi_walk.c (V3) ☆ Strategies for walking the namespace □ arm64 compat Design constraints The loader is meant to be lightweight and prepare the kernel. In order to adhere to that, its initialization of ACPI has been reduced by 130 functions. These functions were picked such that they were not necessary for the above interface, or lacked possibility in the loader. They are: • AcpiInitializeObjects • AcpiInstallNotifyHandler • AcpiRemoveNotifyHandler Some functions needed to be stubbed in respect to the loader’s limited library (specifically in osunixxf.c). Some functions needed to handle physical addresses, rather than virtual memory mappings (specifically in OsdMemory.c). Testing • Confirmation tests were performed, demonstrating that the ACPI namespace is initialized correctly by dumping it in the loader (in C and in Lua) and in the kernel (in C) and comparing the results. • Regression tests were performed, ensuring FreeBSD builds across all architectures with this change. • Unit tests were performed on the Lua bindings, verifying their functionality. Sponsor: Google Summer of Code 2025 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Geomman Release Links: geomman gitlab repo URL: https://gitlab.com/brauliorivas/geomman geomman port URL: https://www.freshports.org/sysutils/geomman Contact: Braulio Rivas Geomman is a partitioning tool (TUI) based on sade(8) that brings more functionality such as copying, pasting partitions, creating ext filesystems or encrypting partitions using geli(8). Geomman is relevant for both newcomers and experienced users because it is a complete and unified management of partitions and disks. Features added to geomman since last report are: • Grow UFS, NTFS, ext2, ext3 and ext4 filesystems. • Shrink NTFS, ext2, ext3 and ext4 filesystems. • New partition dialog, where users can visually select a free space to place the partition to be pasted or moved, added to bsddialog. • Create exFAT, NTFS, ext2, ext3 and ext4 filesystems. • Check all the mentioned filesystems. Then, two GEOM-related features were added too: • Label glabel(8) new partitions. • Encrypt geli(8) new partitions by adding an optional "keyfile", plus a "passphrase" (or passfile). Finally, with the help of Robert Clausecker, we published the geomman port to let people try it out. Future work includes: • Add geomman to FreeBSD natively (userland) • Add ZFS management Sponsor: Google Summer of Code 2025 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Sockstat UI Improvements Links: Sockstat UI Improvements wiki URL: https://wiki.freebsd.org/SummerOfCode2025Projects/SockstatUIImprovements Automatic column sizing PR URL: https://github.com/freebsd/freebsd-src/pull/1720 Reintroduced -w flag PR URL: https://github.com/freebsd/freebsd-src/pull/1746 Microoptimize cap-getnameinfo PR URL: https://github.com/freebsd/freebsd-src/pull/1753 Libxo support PR URL: https://github.com/freebsd/freebsd-src/pull/1770 Revert incorrect use of path-state for SCTP connections PR URL: https://github.com/freebsd/freebsd-src/pull/1799 Complete libxo integration PR URL: https://github.com/freebsd/freebsd-src/pull/1806 Fix port parsing after libxo integration PR URL: https://github.com/freebsd/freebsd-src/pull/1807 Contact: Damin Rido Sockstat is a command-line tool in FreeBSD that displays detailed information about open network sockets. However, its traditional fixed-width formatting made the output hard to read, especially when handling long addresses. This project improves sockstat by introducing dynamically sized columns and structured output support via libxo. With these enhancements, users can more easily read output on the terminal or export the data in formats such as JSON, XML, or HTML for scripting and integration with external tools. The sockstat utility underwent improvements in two phases. First, the fixed-width layout was replaced with dynamic column sizing using a two-pass algorithm to ensure proper alignment and readability, including cases with long socket addresses. The -w option was redefined to enable wide, auto-sized output while maintaining compatibility with default terminal displays. In the second phase, libxo support was integrated by replacing printf() calls with xo_emit(), applying appropriate field tagging, and validating the output using libxo’s tools. The manual pages were updated to document the libxo integration. These changes provide machine-readable structured output while preserving traditional human-readable formatting. Following the sockstat conversion, the parse_ports function was identified as broken. Due to its complexity, the function warranted the addition of unit tests to ensure correct behavior. The issue was addressed by fixing the function and introducing a set of unit tests. The codebase was refactored by renaming sockstat.c to main.c . This project was part of Google Summer of Code 2025. It has modernized sockstat and made it both more user-friendly and better suited for integration into automated workflows. Sponsor: Google Summer of Code 2025 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Process Credentials' Groups-Related Changes in FreeBSD 15 Links: T2 2025 Status Report URL: https://www.freebsd.org/status/report-2025-04-2025-06/#_ucred_group_changes_in_freebsd_15_0 initgroups(3): Backwards-compatible implementation and manual page update URL: https://cgit.freebsd.org/src/commit/?id=9dc1ac869196 Main commit changing getgroups(2)'s manual page URL: https://cgit.freebsd.org/src/commit/?id=4be38acc826f Main commit changing setgroups(2)'s manual page URL: https://cgit.freebsd.org/src/commit/?id=6d22cd6b5f8b Contact: Olivier Certner Contact: Kyle Evans Starting with FreeBSD 15: 1. The behavior of the setgroups(2) and getgroups(2) system calls function has slightly changed. Out of caution, even if almost all existing applications will continue to work undisturbed, we advise auditing those that you are maintaining or using as explained below. 2. How processes' group membership is derived from the password and group databases on login has slightly changed: The login user’s initial numerical group ID from the password database is now automatically added to the supplementary groups set, even if that user is not explicitly listed as a member of the corresponding group in the group database. 3. The kernel stores the effective group ID in a new specific field of struct ucred (cr_gid) instead of in the same array as supplementary groups (cr_ngroups[]). The setgroups(2) and getgroups(2) system calls will operate only on the calling process' supplementary groups, not featuring the effective group ID as the first element of their array argument. The initgroups(3) function’s implementation is unchanged and still relies on setgroups(2), with the consequence that it does not set the process' effective group ID anymore, instead including its basegid argument in the supplementary groups set. One of the reasons for these changes is to have FreeBSD behave exactly like GNU /Linux systems, NetBSD, OpenBSD and illumos-based operating systems. Consequently, almost all portable applications should already be compliant with FreeBSD’s new behavior and will continue to work correctly or even get fixed in the process (see the previous status report linked above for an example with OpenSSH). However, porters, system administrators and users are advised to audit their applications that are using setgroups(2), getgroups(2) and initgroups(3), watching out for the following points: • Applications should already be using setgid(2) or setegid(2) in addition to setgroups(2) or initgroups(3) to set the effective group ID. If this is not the case, these calls must be added, as otherwise affected applications will stop setting the effective group ID starting from FreeBSD 15. • Applications using getgroups(2) should not be treating the first element of the returned array specially, but as any other supplementary group. If nonetheless they do, they have to be modified to obtain the effective group ID via getegid(2) instead and to treat all groups returned by getgroups(2) as supplementary groups only. Manual pages of all changed functions have been modified in stable/14 and stable/15 to describe and contrast the old and new behaviors, and have grown new SECURITY CONSIDERATIONS sections stating the reasons for the changes and the points to watch out for. Backwards-compatible implementations of changed functions are provided so that applications compiled on FreeBSD 14 or earlier continue to see the old behaviors and work as before. They are available if and only if the kernel was compiled with COMPAT_FREEBSD14, which is the case of the default GENERIC kernel. We have normally fixed all unwanted impacts of storing the effective group ID separately from the supplementary groups in the kernel, such as: • Some security policies or access checks would either ignore the effective group ID or the first supplementary group (with lowest numerical ID), affecting process visibility restrictions based on group IDs, the "can debug" and "can export KTLS keys" checks, the mac_do(4) and mac_bsdextended (4) security policies, and access control to some hardware facilities (tracing: hwt(4); performance monitoring: hwpmc(4)) and to NFS-served shares. • Reporting of process' credentials would omit the effective group ID, affecting all variants of procstat -s (on live processes, core files, or system core dump), ddb(4). Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ The Gallant Console Font got Supercharged Links: Gallant Project URL: https://github.com/NanoBillion/gallant Contact: Jens Schweikhardt The vt(4) console font "gallant" was extended in -CURRENT and 14-STABLE. This increased the Unicode glyph count from 502 to more than 4500. Old-timers know and love this font from watching Sun SPARCstations boot. Major additions: • Greek • Cyrillic • International Phonetic Association Extensions • Extended Latin characters • Zapf Dingbats • Tons of arrows • Tons of mathematical symbols • Letterlike symbols and enclosed alphanumerics • Pixel-perfect box drawing • Currency symbols • More punctuation • Just enough Katakana to say コンニチハ • Powerline glyphs in the Private Use Area at U+e0a0 Your help is needed to add more languages. You can contribute via the Gallant Project. But wait, there is more! You do not bother with console fonts and use X11 exclusively? Get that gallant feeling with the new port x11-fonts/gallant and run xterm -fa '' -fn '*-gallant-*' To inspect the available glyphs under X11, run xfd -fn '*-gallant-*' ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Audio Stack Improvements Contact: Christos Margiolis I have been working on the audio stack since 2024Q1. Below is a list of the previous status reports: 2024Q1 URL: https://www.freebsd.org/status/report-2024-01-2024-03/#_audio_stack_improvements 2024Q2 URL: https://www.freebsd.org/status/report-2024-04-2024-06/#_audio_stack_improvements 2024Q3 URL: https://www.freebsd.org/status/report-2024-07-2024-09/#_audio_stack_improvements 2024Q4 URL: https://www.freebsd.org/status/report-2024-10-2024-12/#_audio_stack_improvements 2025Q1 URL: https://www.freebsd.org/status/report-2025-01-2025-03/#_audio_stack_improvements 2025Q2 URL: https://www.freebsd.org/status/report-2025-04-2025-06/#_audio_stack_improvements Important work since last report: • virtual_oss to base port in review: D52308, D52365, D52366, D52426, and more. • snd_hda(4) sound redirection patch (D50070) almost done. • More sound(4) cleanups, fixes and improvements. • More out-of-the-box laptop support. • Wrote BSDCan 2025 trip report for the FreeBSD Journal. • Working on FreeBSD Journal audio article. You can also follow the development process in freebsd-multimedia@, where I post regular reports. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DRM drivers Links: Update to Linux 6.10 DRM drivers URL: https://github.com/freebsd/drm-kmod/pull/371 Contact: Jean-Sébastien Pédron DRM drivers are kernel drivers for integrated and discrete GPUs. They are maintained in the Linux kernel and we port them to FreeBSD. As of this report, we take the AMD and Intel DRM drivers only (NVIDIA FreeBSD drivers are proprietary and provided by NVIDIA themselves). We port them one Linux version at a time. This allows us to ship updates more often and it eases porting and debugging because we have a smaller delta compared to a bigger jump skipping several versions. This quarter, the work was slower with the holidays. DRM drivers from Linux 6.10 were ported. However, there are still issues that need to be worked on: • There is a regression in the integration of the amdgpu driver with vt(4), causing the console to go blank once the driver is loaded. A graphical session still works though. • There are significant changes to the radix-tree support in linuxkpi that needs more testing. • The siphash code committed to linuxkpi is not working yet. The pull request on GitHub and the associated freebsd-src branch may not have the latest versions, until the compilation and load failures are fixed. These updates target the FreeBSD 16-CURRENT development branch for now, but linuxkpi changes should be backported to FreeBSD 15-STABLE. The following pull request did not receive enough reviews and tests for now. That is why they are still in flight. • DMA_BUF_IOCTL_EXPORT_SYNC_FILE and DMA_BUF_IOCTL_IMPORT_SYNC_FILE ioctls • DRM_IOCTL_SYNCOBJ_EVENTFD ioctl They are apparently required to allow the use of wlroots-based Wayland compositors with the Vulkan API (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286311). wlroots will need a patch as well because it only expects these features on Linux for now. Both pull requests rely on patches to linuxkpi. The linuxkpi patches are linked in the pull requests. This work is kindly sponsored by the FreeBSD Foundation as part of the Laptop and Desktop Project. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DRM Drivers Slowdowns and Freezes Fixes Links: Main PR URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277476 drm-kmod GitHub issue URL: https://github.com/freebsd/drm-kmod/issues/302 Contact: Olivier Certner Owners of AMD GPUs using the amdgpu DRM driver from the drm-kmod ports, especially starting with v5.15 (drm-515-kmod), have been experiencing gradual slowdowns and freezes since at least May 2024. Code analysis suggests that recent Intel-based GPUs (gen 13+) may also be affected. We are pleased to announce that, to the best of our knowledge, all these problems have been fixed. We encourage people to test the latest FreeBSD code on branches main, stable/15 or stable/14. The fixes will be included in the upcoming 15.0 and 14.4 releases. Errata notices and patches may be issued for 14.3 in order for people not to have to wait until 14.4 (whose release should tentatively happen next March). An additional fix will find its way in the drm-kmod ports (see below). Investigations revealed that the crux of all these problems has been bad handling of too frequent, and generally not really necessary, physically contiguous memory allocation requests in fast paths. Basically, the DRM’s TTM component tries to allocate pools of graphics memory pages that are as much as possible physically contiguous in order to reduce the number of corresponding TLB entries. It does it in a loop that first tries to allocate pages of higher order with the __GFP_NORETRY flag, gradually falling back to smallest ones (see ttm_pool_alloc()). The first problem is that our LinuxKPI did not handle Linux’s __GFP_NORETRY flag and would try hard to fulfill the first requests, i.e., those with highest order pages, using expensive mechanisms to obtain or produce contiguous memory if not readily available. A first fix by Mathieu (sigsys at gmail with regular company suffix) removed memory compaction from this process (foregoing calls to vm_page_reclaim_contig()). This fix was then completed by stopping the VM system from trying to break memory reservations, which are pieces of a speculative mechanism that tries to automatically provoke the use of superpages. Another problem came from evolutions of our LinuxKPI. In order to better comply with what Linux does, kmalloc() was changed to always return physically contiguous memory. Unfortunately, kvzalloc(), which relied on kmalloc() in our implementation (which was conceptually wrong, but initially harmless in practice), was not switched to rely on kvmalloc() in the process, effectively turning large memory allocations of zeroed pages into costly physically contiguous ones. Some rough profiling of slowdowns was done using dtrace. It revealed that a fair amount of execution time of the failing allocations came from attempting multiple allocations in the same NUMA domain. An analysis of the VM domainset iterators code revealed multiple flaws, in particular leading to re-examining the same domain multiple times (up to 4 times for the common case of machines with a single domain) without any additional guarantees of success for new attempts. Some other VM domainset problems have been fixed in the process, such as ensuring that allocation requests prefer domains not on a low memory condition in all situations. As for succeeding allocations, they would trigger useless changes to page attributes, leading to expensive TLB shootdowns. Finally, concerning specifically the amdgpu driver and affecting only Carrizo, Polaris and Vega M based AMD GPUs, a temporary allocation that was unnecessarily physically contiguous was replaced with a regular one, making the remaining, relatively short but noticeable freezes disappear. By contrast with those evoked above, this change is to the drm-kmod ports' code. It has been included in the latest version bumps in the ports tree. Check that your package versions, for drm-510-kmod, drm-515-kmod, drm-61-kmod and drm-66-kmod, are respectively equal or greater than 5.10.163.*_13, 5.15.160.*_8, 6.1.128.*_7 and 6.6.25.*_6, where * stands for the __FreeBSD_version value on the build system. This work was sponsored by the FreeBSD Foundation as part of the Laptop Project. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ LinuxKPI 802.11 and Native Wireless Update Contact: Bjoern A. Zeeb Contact: The FreeBSD wireless mailing list This report focuses on the efforts using permissively licensed Linux wireless drivers, mostly unmodified, on FreeBSD, as well as preparing the native net80211 stack for support of newer standards. Work is ongoing for Mediatek mt76-based PCIe card support. LinuxKPI 802.11 (linuxkpi_wlan(4)) updates were committed for scanning and beacon handling improvements and more robustness. LinuxKPI updates were done in order to import newer versions of iwlwifi(4), rtw88(4), and rtw89(4) drivers. Work on suspend and resume for LinuxKPI-based wireless drivers has a possible solution which will need community testing and feedback. Both updates were blocked by out-of-tree drm LinuxKPI PCI conflicts and problems were just resolved before EuroBSDCon 2025 thus the work will likely appear beginning of 25Q4. I gave a talk on wireless at EuroBSDCon 2025 and had a good chat with wireless people from NetBSD and OpenBSD. There is increasing interest again in getting brcmfmac support sorted, as well as more requests for ath11k. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ mac_do(4) and mdo(1) Improvements Links: Wiki page URL: https://wiki.freebsd.org/SummerOfCode2025Projects/MacDoAndMDoImprovements Commit to mdo(1) enabling fine-grained credentials transition requests URL: https://cgit.freebsd.org/src/commit/?id=3ca1e69028ac Contact: Kushagra Srivastava Contact: Olivier Certner The mac_do(4)/mdo(1) project aims at allowing controlled process credentials transitions without using setuid executables but instead leveraging our MAC framework. For more information, please consult the associated manual pages as well as previous status reports from T3 2024 and T4 2024. As part of Google Summer of Code 2025, Kushagra worked on extending mac_do(4) (kernel) and mdo(1) (userland). Worked-on mac_do(4) features: • Per-jail configuration of authorized executables: Allow administrators to specify a per-jail list of executables that are permitted to request credential transitions, instead of being limited to the hardcoded /usr/bin/ mdo. • Support for traditional credential-changing system calls: Allow mac_do(4) to assess calls to setuid(2), setgid(2), setgroups(2), and related functions as full credentials transitions on their own. Worked-on new mdo(1) features: • Allow finely specifying target groups (-g, -G, -s options), inheriting from current credentials or those of some user in the password and group databases, and explicitly overriding any user and group IDs and supplementary group. • Provide a --print-rule option to switch to a mode that displays an example of the target part of a rule that would match the requested credentials. Of these, the mdo(1)'s new fine-grained credentials transition requests change has been committed and will appear in 15.0 and 14.4. The others most probably will land in stable/14 before 14.4, but seem unlikely to appear in 15.0 as they need more review and some amendments. Together, these improvements will make mac_do(4) and mdo(1) more flexible and practical, enabling safer credentials transitions without relying on setuid executables and with strong jail integration. Sponsor: Google LLC (Google Summer of Code 2025) Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Suspend/Resume Improvement Links: Blog URL: https://obiw.ac/s0ix/ BSDCan talk on s2idle/S0ix URL: https://youtu.be/RCjPc4X2Edc Sleep testing image URL: https://people.freebsd.org/~obiwac/s0ix/ Working Repository URL: https://github.com/obiwac/freebsd-s0ix/tree/everything Tip of the s2idle/S0ix + AMD SMU stack URL: https://reviews.freebsd.org/D48721 Contact: obiwac Suspend-to-idle and support for S0ix sleep is in the process of being added to FreeBSD. This will allow modern Intel and AMD laptops, some of which do not support ACPI S3 sleep, to enter low power states to increase battery life. Entry to S0i3 is now working reliably on the Framework 13 AMD Ryzen 7040 series laptops on FreeBSD 15. This required changes to LinuxKPI for DRM to know whether the system intends to enter S3 or S0ix: D51591. These changes in turn required the creation of generic sleep types, separate from ACPI. Not all of these changes have yet been committed, but new hw.power.* sysctls will be created to choose the sleep type for various sleep state transition requests. The amdsmu driver, some ACPI changes and fixes, and GPIO interrupt servicing in amdgpio have been committed. A pre-built sleep testing image is now available to easily testing S0i3 entry on machines. Detailed instructions are on the webpage. With respect to the links, the blog post entry is still outdated. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ USB Kernel Debugging Improvements Contact: Tom Jones XHCI USB controllers offer a mode which allows them to be used as a system debugging interface. XHCI debug uses a special USB 3 cable with VBUS, D+ and D- disconnected. The feature can be used to live debug the FreeBSD kernel, enabling investigation of issues which cause the system video console to lock up and there is not an alternative such as a serial console. This can happen when debugging issues with graphics drivers. Hiroki Sato developed support for the XHCI debug interface and made it available as some in progress git branches. This implementation enables FreeBSD to operate as both a Debug Host and a Debug Target, with support for debugging from the loader through to the kernel. In this quarter the Debug Host side of the XHCI debug has been committed to FreeBSD main and will be available in FreeBSD 15. The Debug Host driver enables a FreeBSD machine to debug Linux and Windows systems acting as Debug Targets. The Debug Host driver has been split from the patch series to enable debugging of FreeBSD 16 and onwards from FreeBSD 15. The Debug Target side of XHCI debug has progressed in this quarter, with an improved interface between the loader and the kernel and a lock up sending data from a Target resolved. The remaining work for the host implementation is to enable XHCI debug as a console very early in boot and to convert some methods to use bus space allocations. In the coming quarter I plan to update the developers handbook section on kernel debugging. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for new hardware platforms. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Driver Development for BananaPi-R64 Links: Wiki URL: https://wiki.freebsd.org/arm/Bananapi Contact: Martin Filla Introduction The Banana Pi R64 is a MediaTek MT7622-based development board (ARM Cortex-A53, dual-core ~1.35 GHz) featuring 4× Gigabit LAN, 1× Gigabit WAN, Wi-Fi (4×4n), Bluetooth 5.0, and multiple peripheral interfaces (UART, SPI, I²C, GPIO, SATA, mini-PCIe, eMMC, etc.). Current State of FreeBSD Support • Implemented so far: □ UART driver □ Clock management (clocks) □ Pinctrl/gpio driver – in active development gpio part □ Storage controllers (eMMC/SD/MMC) driver □ Ethernet Switch mt7531 driver □ Ethernet mt7622 driver Other essential components—Ethernet, USB, SATA, Wi-Fi, etc.—are not yet implemented. Technical Context and Significance Support for Banana Pi R64 in FreeBSD is in the early stages—UART and clocks drivers exist but ppl clock is under development, gpio is under development — while most critical subsystems remain unimplemented. Development roadmap • Implement missing drivers □ USB (XHCI/OTG) □ SATA / AHCI □ Wi-Fi (likely MediaTek MT7615) □ GPIO subsystems Conclusion Support for Banana Pi R64 in FreeBSD is in the early stages—UART and clocks drivers exist but ppl clock is under development, gpio is under development—while most critical subsystems remain unimplemented. Publishing working code and artifacts, plus active collaboration with the FreeBSD community, will be essential to bring this board toward usable status under FreeBSD. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cloud Updating cloud-specific features and bringing in support for new cloud platforms. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Improvements for nuageinit Contact: Baptiste Daroussin Contact: Jesús Daniel Colmenares Oviedo Inspired by cloud-init, nuageinit is a script written entirely in Lua to add cloud-init compatibility to FreeBSD. Thanks to the firstboot feature of the rc (8) framework, it runs early and only once. Fixes and improvements have been made in recent months: • Missing documentation for already implemented parameters have been added. • More test cases have been added. • The device configuration ID is used as an interface when no match rule is specified. • Implementation of the network.ethernets.{id}.match.name parameter. • Implementation of the network.ethernets.{id}.wakeonlan parameter. • Implementation of the network.ethernets.{id}.set-name parameter. • Implementation of the network.ethernets.{id}.match.driver parameter. • Implementation of the network.ethernets.{id}.mtu parameter. • Implementation of the nameservers parameter. • Support for security/doas. • Allow the use of network parameters from network-config file. Committed in the following branches: stable/14, stable/15, and main. If you plan to use nuageinit, remember that each image is generated periodically and distributed on the following sites: • https://download.freebsd.org/releases/VM-IMAGES • https://download.freebsd.org/snapshots/VM-IMAGES Commits: ba5df7a, 95b0be1, a7f1996, 9f3330f, 9f3330f, 95230b2, 9a829e8 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Engineering Team Links: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/ FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/ Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-doceng Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. Team changes: • doceng@ welcomes ziaee@ as a new member (lurker). • ebrandi@ promoted to full doceng@ membership. During the last quarter: • vladlen@ obtained a translator commit bit, with maxim@ as mentor. • reactivation of documentation commit bit for andy@ with both mentors carlavilla@ and maxim@ Document changes • Handbook □ The X11 chapter has been updated and restructured Many style and content fixes in various documents. • Documentation repository: □ Added manual pages for macOS 26.0 □ Updated manual pages for macOS to 14.8 and 15.7 □ Added manual pages for Debian 13.0.0 FreeBSD Translations on Weblate Translate FreeBSD on Weblate URL: https://wiki.freebsd.org/Doc/Translation/Weblate FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/ Q3 2025 Status Languages • Chinese (Simplified) (zh_CN) (progress: 7%) • Chinese (Traditional) (zh_TW) (progress: 3%) • Dutch (nl_NL) (progress: 1%) • French (fr_FR) (progress: 1%) • German (de_DE) (progress: 1%) • Greek (progress: 1%) • Indonesian (progress: 1%) • Italian (it_IT) (progress: 4%) • Korean (progress: 29%) • Norwegian Bokmål (progress: 1%) • Persian (progress: 3%) • Polish (progress: 1%) • Portuguese (progress: 0%) • Portuguese (Brazil) (progress: 23%) • Russian (done: 100%) • Spanish (progress: 35%) • Turkish (tr_TR) (progress: 1%) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. Packages maintained by DocEng During this quarter the following work was done in packages maintained by doceng@: • www/gohugo: update to 0.151.0 Open issues There is 1 Open PRs in bugzilla assigned to doceng@: • 267274 Please remove the zh-CN Handbook of the current FreeBSD website ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ The FreeBSD Russian Documentation Project Links: FAQ URL: https://docs.freebsd.org/ru/books/faq/ Web URL: https://www.freebsd.org/ru/ The FreeBSD Russian Documentation Project site URL: https://github.com/freebsd-doc-ru/freebsd-doc/discussions Contact: Andrey Zakhvatov Contact: Vladlen Popolitov The FreeBSD Russian Documentation Project’s current goal is to provide up-to-date Russian translations of the most important parts of the FreeBSD documentation (FAQ, Handbook, website content). It is essential to support Russian-speaking users with high-quality official technical materials and to increase the adoption of the operating system worldwide. We hope this initiative will gain support within the Russian-speaking FreeBSD community and lead to an increase in translated materials. In September 2025, two committers were granted commit bits to write Russian-translated documentation into the FreeBSD documentation tree: • Andrey Zakhvatov, co-mentors Sergio Carlavilla and Maxim Konovalov • Vladlen Popolitov, mentor Maxim Konovalov During the last quarter: • 100% of the text has been translated in Weblate. • 31 out of 47 documents have been updated to the latest version from docs.FreeBSD.org/ru, with the remaining documents currently under review and awaiting commit. This report acknowledges with appreciation the contributions of the following colleagues who performed reviews of our commits during the quarter (in Phabricator or by email): • Gleb Popov • Benedict Reuschling • Eugene Grosbein • Maxim Konovalov • Michael Zhilin Plan for next quarter: • Finalize the review and commit process for documentation (books and articles) • Restore the Russian pages on www.FreeBSD.org • Review the feasibility and the mechanics of the man pages translation Check the official translation guide if you would like to help. We would appreciate your assistance with translating the following materials: • Web pages ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A bhyve management GUI written in Freepascal/Lazarus Links: Bhyvemgr URL: https://github.com/alonsobsd/bhyvemgr/ Contact: José Alonso Cárdenas Márquez Bhyvemgr is a bhyve management GUI written in Freepascal/Lazarus on FreeBSD. It needs a bunch of tools, mostly installed on base system, and some installed from ports/packages. The main goal is to be a desktop application with focus on desktop users to easily and quickly setup and run virtual machines on FreeBSD hosts. During this quarter, there were many bugfixes and improvements to Bhyvemgr. These are some highlights that were added: • Add swtpm support to FreeBSD >=1403000. • Add x86.verbosemsr setting on FreeBSD >=1500023. • Add IPv6 support. It enhances a better IPv6 support using dns/dnsmasq. A host-record will be added to dnsmasq when Use_IPv6 is enabled. • Add a bridge IPv6 calculator at Bhyve Manager Settings. It helps us to calculate what IPv6 must be assigned to bridge interface. Take a look at README for more information about that. • Add support to create virtual machines from Cloud or VM images. A new page will appear when "Create a virtual disk from image" option is selected. It includes an image downloader (only support img.xz, raw.xz, qcow2.xz, qcow2, img, and raw files). • Add Cloud init/Nuageinit configuration files support. • Add user-data, network-config, and meta-data templates used from image minimal configuration. • Add user-data, network-config, and meta-data samples files. • Add support to define static ipv4 address when files configuration is selected from "Create Virtual Machine/Image" form. • Add new option to select images path directory from "Settings". This directory is used to storage extracted images files. By default, it is located at ~/.bhyvemgr. • Add new option to define qemu-img path file. • Add i18n support with initial English, Simplified Chinese (thanks to ykla) and Spanish translations. • Enhanced logging support. • Enhanced clipboard support. Bhyvemgr supports aarch64 from 15-PRERELEASE to 16-CURRENT and amd64 from FreeBSD 13.x to 16-CURRENT. Also, sysutils/bhyvemgr can be compiled or installed from ports or pkg binaries with gtk2, qt5 or qt6 interface support. People interested in helping or supporting the project are welcome. Sponsor: https://paypal.me/alonsocbsd Current version: 1.12.0 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Container orchestration: Overlord, Director, AppJail and cloud-init Links: AppJail on GitHub URL: https://github.com/DtxdF/AppJail Director on GitHub URL: https://github.com/DtxdF/Director Overlord on GitHub URL: https://github.com/DtxdF/Overlord Makejails URL: https://github.com/AppJail-makejails Contact: Jesús Daniel Colmenares Oviedo AppJail is an open-source BSD-3 licensed framework entirely written in POSIX shell and C to create isolated, portable and easy to deploy environments using FreeBSD jails that behaves like an application. Director is a tool for running multi-jail environments on AppJail using a simple YAML specification. A Director file is used to define how one or more jails that make up your application are configured. Once you have a Director file, you can create and start your application with a single command: appjail-director up. Overlord is a fast, distributed orchestrator for FreeBSD jails oriented to GitOps. You define a file with the service intended to run on your cluster and deployment takes seconds to minutes. This orchestration tool uses AppJail, Director and can even create VMs with vm-bhyve, but as its philosophy is "deploy using code" you can create a single file once and deploy many times. Through a tree chaining system Overlord deploys jails on connected systems sharing their resources almost infinitely. See the wiki for articles that use Overlord. Recently written articles about Overlord: • Overlord: Deploy Jails as Fast as You Code • Deploying virtual machines using cloud-init • Deploying virtual machines with ephemeral jails • Using GitOps with Overlord • How to install Jellyfin and Jellyseerr using Overlord Makejails are simple text files that automate the steps to create a jail, a widely used feature of AppJail. Currently, there are many Makejails created and hosted in the Centralized Repository, but here are some of the recently written ones: • Odoo • WriteFreely • Adminer • Shiori • Healthchecks • ntfy Sponsor: https://www.patreon.com/appjail ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Improve libvirt support for bhyve hypervisor Links: CI for libvirt/bhyve on FreeBSD URL: https://empt1e.blogspot.com/2025/09/ci-for-libvirtbhyve-on-freebsd.html Contact: Roman Bogorodskiy Completed work • Support for pf(4)-based NAT networking was merged and has been available since libvirt 11.7.0 release. • Domain usage statistics reporting is also available starting with libvirt 11.7.0 release. • TCP console support has been available since libvirt 11.6.0 release. • The libvirt testing project, libvirt-tck, can now successfully run domain, network, and storage tests against the bhyve driver. Plans for the next quarter • Extend libvirt-tck testing with hooks tests. • Add support for: □ Boot order configuration. □ TPM devices. □ Snapshot/resume to the bhyve driver (targeted, but might roll over to next quarter). • Improve virt-manager support on FreeBSD. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Improve OpenJDK on FreeBSD Links: Project description URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/ Project repository URL: https://github.com/freebsd/openjdk Contact: Harald Eilertsen FreeBSD Java mailing list The goal of this project is to improve OpenJDK support for FreeBSD/amd64 and FreeBSD/arm64. Java is an important runtime environment for many high performance, critical enterprise systems. Making sure Java based applications run correctly and efficiently on FreeBSD is important to ensure that FreeBSD will continue to be a viable and attractive platform for enterprises, as well as businesses and organizations of all sizes. In this quarter the following issues/milestones were reached: • The OpenJDK 24 port was updated to OpenJDK 24.0.2, and once more to include several fixes for the serviceability agent and performance improvements for large Elastic- and OpenSearch workloads. The serviceability improvements fixes symbol and thread lookups when attaching to another JVM, and fixes loading core files in the Java debugger on FreeBSD. • The OpenJDK 23 port was updated to include IPv6 dual protocol socket support (like OpenJDK 24), as well as the performance improvements for Elastic- and OpenSearch. • OpenJDK 8, 17 and 21 were updated to the latest releases from upstream, and a new port for installing just the Java Runtime Environment (JRE) of OpenJDK 21 was added. • Build issues causing the official pkg builds of some older java versions on certain FreeBSD revisions to fail, was debugged and fixed by Ronald Klop. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ KDE on FreeBSD Links: KDE/FreeBSD initiative URL: https://freebsd.kde.org/ FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD Contact: KDE on FreeBSD Mailing List The KDE on FreeBSD project packages CMake, Qt, and software from the KDE Community, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team is part of desktop@, building the software stack to make FreeBSD beautiful and usable as a daily driver graphical desktop workstation. We missed last quarterly status report. The changes from the second quarter are included in this report. Infrastructure CMake was updated to 3.31.9, the latest release in 3.x series. Ninja was updated to 1.13.1. Qt6 was updated to 6.9.2. Both of the Python bindings for the Qt6 toolkit have been updated to their latest releases: • PyQt6: updated to 6.9.1 • PySide6: updated to 6.9.2 The graphics/qt6-wayland port was patched to fix crashes of Plasma on Wayland when right-clicking the desktop. Qt5 was updated to 5.15.17 KDE patch collection. Upstream standard support for Qt5 is officially over. This might be the last update for Qt5 on FreeBSD. The www/qt5-webengine port has been updated to 5.15.19 with security patches up to Chromium 135.0.7049.95. The Qt5 WebEngine component, however, is and forever will be based on Chromium 87.0.4280.144, which is over 4 years old. Security updates for the underlying Chromium base have now ceased. Use at your own risk. KDE Stack KDE Frameworks, Plasma, and Gear release happen very regularly. KDE team lands these updates shortly after their upstream release. • KDE Frameworks reached version 6.18.0. • KDE Plasma Desktop was updated to 6.4.5. • KDE Gear was updated to 25.08.1. Plasma 6.5 Beta (6.4.90) was ported but not committed to the main ports-tree. The net-mgmt/kf6-networkmanager-qt port with stub implementation for Linux NetworkManager was added to aid porting third-party software. Related Ports The KDE team maintains a wide range of ports and updates them all as needed. According to Portscout less than 0.7% ports are outdated. The KDE team would like to thank Dima Panov, Gleb Popov, Jason E. Hale, Kenneth Raplee, Loïc Bartoletti, and Max Brazhnikov for keeping things up-to-date. The KDE team is grateful to Harley (SponiX on IRC) for sharing his building box. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GCC on FreeBSD Links: GCC Project URL: https://gcc.gnu.org/ GCC 13 release series URL: https://gcc.gnu.org/gcc-13/ GCC 14 release series URL: https://gcc.gnu.org/gcc-14/ GCC 15 release series URL: https://gcc.gnu.org/gcc-15/ GCC 16 release series URL: https://gcc.gnu.org/gcc-16/ Contact: Lorenzo Salvadore The exp-run to update GCC default version from 13 to 14 is almost done at the time this report is written: only one last PR stays open. Hopefully, the update has been finally done when you are reading these lines. However I remind you that the latest GCC major version is GCC 15, so we will still be behind one version. Of course, another exp-run will be prepared to update GCC_DEFAULT to GCC 15, but not immediately. I will wait some time to ensure that the GCC_DEFAULT=14 update has indeed worked as expected and to deal with some other issues related to the GCC ports. Another important change concerns bootstrapping. The GCC ports were in an inconsistent state: some ports required a bootstrap option to be chosen, while others did not. Now all GCC ports allow building without any bootstrap option selected, just as it was in the past. The problem is that building GCC on FreeBSD with FreeBSD’s default compiler (clang) is not fully supported. Since I know that many users do prefer to build GCC without bootstrapping it, instead of enforcing it as I initially planned, I prefer to maintain the option but remove from a no-bootstrap build all features that cannot be built successfully. It shall be the users' responsibility to ensure that they do not need any feature incompatible with no-bootstrap builds. At the moment, jit is the only feature that is excluded from a no-bootstrap build. The default bootstrap option is STANDARD_BOOTSTRAP, so users of packages from official FreeBSD packages repositories will have a full build with all the supported features available. See commits 5ee63cc45413954077b2b0c0546b8342585b41ba, 62f186cdf6e9689f30e854a0e23482c552c851a2 and this mail for more details. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Valgrind: preparing for 15.0-RELEASE Links: Valgrind Home Page URL: https://www.valgrind.org/ Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html arm64 port URL: https://github.com/paulfloyd/freebsdarm64_valgrind Contact: Paul Floyd I have not submitted any reports for over a year. On the whole that is good news as it means that there have not been any major issues. Back then I said that aarch64 support was about to land and indeed it did in mid April 2024. I added a nice little script for use with Valgrind called vgscript. This works in a similar manner to pstack (or bstack on FreeBSD) in that you give it a PID and it will generate a stack trace for that process. If you use bstack with a Valgrind process you will see the Valgrind call stack which is probably of no use to you. If you run vgstack with a Valgrind PID it will print the call stack of the test exe running under Valgrind. If you use Valgrind regularly could you take a look and answer the survey that I posted on the forums (if you have not done so already). Here is the link. Valgrind 3.26 is due out at the end of October 2025 and devel/valgrind will be updated shortly after that. devel/valgrind-devel will get one (or maybe more) updates as I fix issues with FreeBSD 15.0. The outstanding issues that I have on FreeBSD 15.0 are * aarch64: there is a problem when using Valgrind with gdb/vgdb. Hitting ctrl-c to interrupt the process running under Valgrind does not work and Valgrind crashes with an assert. * aarch64: a known old issue that was infrequent regarding initialisation of thread memory now seems to occur much more often. * amd64: maybe similar to the first issue with gdb/vgdb and interrupting a process, but this time I am seeing select return an 'impossible' value. * amd64: a test for setcred is getting an extra "Conditional jump" error message. Most of the above are not too serious unless you are a heavy user of gdb/vgdb. Here is a list of bugfixes since my last report, Q1 2024. • Several suppressions added for libc, libc and libstdc functions • Improvements to setcontest argument checking • Some more aio_* fixes • Syscall _sysctlname was checking the wrong length of the name argument • New syscall wrappers for kcmp, getrlimitusage, close_range, fchroot, setcred, exterrctl, inotify_add_watch_at, inotify_rm_watch, jail_attach_jd and jail_remove_jd • Started adding better ioctl argument checking • Fixes to Valgrinds self-checking modes • Support aarch64 auxv AT_HWCAP, AT_CHERI_STATS, AT_HWCAP3 and AT_HWCAP4 • Valgrind file descriptor checking has been significantly enhanced and this includes FreeBSD • Some old code that I could never test for FreeBSD 10 has been removed • Removed as much as possible FreeBSD version dependent code. This reduces everyday maintenance at the cost of making version-independent regression tests more difficult • Turn off check for lock created during text handling that will deliberately leak • Syscall sigwait was not correctly dealing with its atypical return value • Improved checking of utrace syscall arguments • amd64: syscall arguments 7 and 8 were swapped (it turns out that argument 8 is never needed and has been removed) • amd64: added sysarch subcommands AMD64_SET_TLSBASE and AMD_GET_TLSBASE • Reduced warnings that get printed in quiet (-q) mode • Improved checking done by sysctl kern.proc.pathname • Handle mmap MAP_STACK and MAP_GUARD • Syscalls open* now produce an error if you try to open the guest exe for writing • Syscalls sigwait and sigwaitingfo were too lax in accepting NULL arguments • Many of the *at system calls (like faccessat) were not checking that the directory fd is not one of the file descriptors reserved for Valgrind’s use • Function memalign now accepts a size of zero ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A new Wi-Fi management utility: wutil Links: source code URL: https://github.com/MainKt/wutil port URL: https://www.freshports.org/net/wutil Contact: Muhammad Saheed net/wutil is a Wi-Fi management utility that supports most wpa_supplicant(8) station-mode operations (scanning, connecting or disconnecting from wireless networks, and managing known networks, etc.), accessible with much nicer interfaces. It also automatically manages and updates wpa_supplicant.conf(8). SSIDs with Unicode characters are also handled nicely. wutil(8) is the Command-Line Interface (CLI), whereas wutui(8) is the Terminal User Interface (TUI). wutui was built without any dependency on TUI libraries, by just spell-casting ANSI escape sequences in uncooked terminal raw mode and a kqueue(2) based event loop. Both utilities communicate with wpa_supplicant via its control socket interface. There is also a dependency on net/libifconfig for interface related functions. In the future, I plan to support AP-mode operations from hostapd(8), clean up the TUI components and perhaps move away from wpa_supplicant to handle authentication in-house. wutil is now available in ports. Give it a whirl! Contributions, bug reports and feature requests are very welcome on GitHub. Mentors: Aymeric Wibo and Getz Mikalsen Sponsor: Google Summer of Code 2025 From nobody Sun Nov 30 13:51: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 4dK7kM1n9Gz6JWXD for ; Sun, 30 Nov 2025 13:51:55 +0000 (UTC) (envelope-from brnrd@freebsd.org) Received: from smtp-out08.qsp.nl (smtp-out08.qsp.nl [193.254.214.172]) (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 "*.qsp.nl", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dK7kK6GhJz4Cs7 for ; Sun, 30 Nov 2025 13:51:53 +0000 (UTC) (envelope-from brnrd@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 193.254.214.172 is neither permitted nor denied by domain of brnrd@freebsd.org) smtp.mailfrom=brnrd@freebsd.org Received: from 5921114a.static.cust.trined.nl (5921114a.static.cust.trined.nl [89.33.17.74]) by smtp02.qsp.nl (Postfix) with ESMTPSA id CE1F32CF7 for ; Sun, 30 Nov 2025 14:51:41 +0100 (CET) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by 5921114a.static.cust.trined.nl (Postfix) with ESMTPSA id 4dK7k26V6nzDbJ for ; Sun, 30 Nov 2025 13:51:38 +0000 (UTC) Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-37a415a22ecso30873101fa.0 for ; Sun, 30 Nov 2025 05:51:39 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWvv7AGkFIgf0ObyM80PvbEHOjRYwrcg5QnKVXKOhHLNuUb1fZy8hsanrBBrSISjKtEcUwuRb5x4SrOWbcKlGo=@freebsd.org X-Gm-Message-State: AOJu0Yxcg/dyV+fGZhKVKpzuvJDZQOyzYPJi0O9QZ12fpP4rwf71lYiD l9I8MaJNzGo6FzV2ovWlLNcRQNOCuIQqMTAQBydMj/X+hrybTCTxfrxdsczk9/XP6h/CLjpkMjS c8jfolMASjgPd9ui+iBHKxtNQpj1syA== X-Google-Smtp-Source: AGHT+IGzxFcujESTFCaJ+LivmtPjiojX0uPDTe6PQ72TNDFxN7RAizJe+Eu8SO2/EAJ7sDpW/hb5nLNXVCB20rUWoAI= X-Received: by 2002:a05:651c:884:b0:377:d151:c090 with SMTP id 38308e7fff4ca-37cc82aef0cmr109480161fa.1.1764510698674; Sun, 30 Nov 2025 05:51:38 -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: Bernard Spil Date: Sun, 30 Nov 2025 14:51:29 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bm8ItdFGPyMSh7aaaWBR_hF4iVtcmLXR_5FxleINcWH_g2tw1mV0GujvlU Message-ID: Subject: Re: looking for testers for if_rge - RTL8125/8126/8127 ethernet driver To: Adrian Chadd , Alex Dupre Cc: Florian Smeets , FreeBSD Net , freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.94 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.944]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[brnrd]; BLOCKLISTDE_FAIL(0.00)[89.33.17.74:server fail,193.254.214.172:server fail,209.85.208.181:server fail]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.181:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4dK7kK6GhJz4Cs7 Hi all, Thanks to flo for notifying me that there's an alternative to net/realtek-re-kmod. I've had crashes running realtek-re-kmod and realtek-re-kmod198 before, none of the switches seemed to help. After upgrading to from 14.3 to 15.0-RC4-p1, I thought I'd test again. So far so good, no crashes. Generating load with iperf for 5 minutes from 2 machines to the server works OK with the 1101.00 for now. Nice to have this if_rge in the back pocket when things don't work out with 1101.00. Started porting it, find the patch at https://brnrd.eu/bsd/patch-net_realtek-rge-kmod-20251129 Seeing that this is supposed to land in base, I'm holding back on committin= g it. Thanks all! Bernard (brnrd@) On Fri, Nov 28, 2025 at 5:48=E2=80=AFPM Adrian Chadd w= rote: > > On Thu, 27 Nov 2025 at 10:13, Florian Smeets wrote: > > > > On 23.11.25 03:16, Adrian Chadd wrote: > > > hi! > > > > > > i've ported Kevin Lo's openbsd driver for these realtek chipsets to F= reeBSD. > > > It works well enough for me to use on my laptop w/ RTL8125B / Killer = E3000. > > > I'm now opening it up to others who are willing to build/run a kernel > > > module to test the driver out and report back. > > > > > This is great. Finally, an in tree driver for these very common NICs. > > The 1100.00 version of the net/realtek-re-kmod was just unreliable for > > me (constant hangs, no matter which options I turned off and on). I've > > only done light testing with the official 1101.00 driver. I was able to > > wedge it with less than a minute of iperf3, and the ifconfig down/up > > dance that was able to revive the interface with 1100.00 was not able t= o > > recover the interface. > > > > I ran if_rge on my NAS and did some testing. I haven't had one hang wit= h > > this driver, even after pounding the network for hours. That's a big > > plus for me. Thanks. > > > > I was able to achieve close to 2.5Gb/s TX and close to 1Gb/s RX with > > iperf3 --bidir. > > > > CPU usage appears to be substantially higher than with the official > > Realtek driver. > > That's a good data point. > > > > > [intr{irq59: rge0}] goes to around 50% of one core, and [kernel{rge0 > > taskq thread}] hovers between 20-25% when running the above iperf3 test= s. > > > > With the official 1101.00 driver, the only process using > 1% CPU is > > this one [kernel{re0 taskq}] and it is around 10% with the test > > mentioned above. > > I'll go dig into that a bit. It shouldn't be taking very much CPU to proc= ess > this number of packets; the bulk of the CPU should be used by the IP stac= k. > > I'll go run some profiling over the next few days and see if I can nail d= own > what I'm doing poorly. Hopefully it's something stupid on my end. ;-) > > > > -adrian > From nobody Sun Nov 30 16:20: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 4dKC1Q5VY0z6HqMb; Sun, 30 Nov 2025 16:20:10 +0000 (UTC) (envelope-from markj@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 4dKC1Q4w2Zz3FmR; Sun, 30 Nov 2025 16:20:10 +0000 (UTC) (envelope-from markj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764519610; 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=9w+RLECyI+C8nRHvY0DY/hWqIHCa1X55x4McqWFX+Qk=; b=CrNavD/lSTplvU9NMINRDetjXI1JXaFLyfNLl2k3bKgJSkNgfhVhyOZghRdaHOaZEO9Z1i HZjvXxB1VH2AIz73VtSdKE1CpFkngohC0FD+MhbQG3jGdJu4e2nt/tpfz4/5OPwMGmPseJ oBOPAo3F/nlw8zhs9/ckS8ssPEZ63ubtL5wkwg5hF4HwLlj846XIHhlrqk18snMvFlEzlH XnM822vwz9faJdnkuNmZXbAD4rtf52KZO1a1nFRyBCFMs4WhHBZv5a3jo6kjV5k8ahVgvQ wmQ20Qo/HVtW/eIpYv891eGqFE7c0unDwHmK1TH80OAcTXeyKB5bRdqtx33GqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1764519610; 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=9w+RLECyI+C8nRHvY0DY/hWqIHCa1X55x4McqWFX+Qk=; b=BZeodxFJ2TjOriqfHRfsE8Y4BPrUIv5c8nKjzOie7/szWYWurgFauvI/sHwmtifhk5G8lj uCEeiM2kibVuzAib4vBZiKalsQGIdknsCUC3Le3qHAHzAFNrMhr8yoE/vOT/Yuxwqbuami hAUQbOuquwW7eL+mW8pcxlpFTCVOerXpeWoUTW5x/+DWZBIX1+iCB1UdkZGnJMQLQtzEr9 rQSCDHKjWsBpK/YO6bYAQSvm0UDL0oUn+NxAsLIw0FGWnk/EPtc2EkBBLJm3x53mBFUR+Q 0tsz6p/gfV7qyadK0hiJVwjcFt989s2vAV/52fNM0siU01IweOGsN0hGQHunXA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1764519610; a=rsa-sha256; cv=none; b=GXyDeffy1R8j26yUdD68cFeX7/PUCgjFyPC34GnmuW64gFgTRtA51UP4y4xbhLIjgddUX9 kQYlUl8ISvlwC2BBE/34j5Y7C43DgyuEwaZiT0ZfDdQLBrdkY6y15G9vkQXkceFC1oNn4i QXoFzNDEcFhJs9vtAWoDo5ngyfCBYmojF1ngnFJBqkBJR20xyY6m7H9xI85LhlohgXj97l My2ylPGAYTCBirG/00CdDOcVwz40BOUUA6J7SV3l32dJTaBTQH7gLSvxq7enrEaij+nmwA cVn+GiEhacFbo1ps7e56OVi4mn9nHec4MXEy3+nEleKwinEv+78tZm2MyEA9uw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from nuc (192-0-220-237.cpe.teksavvy.com [192.0.220.237]) (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: markj) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dKC1Q2n4dz17Cw; Sun, 30 Nov 2025 16:20:10 +0000 (UTC) (envelope-from markj@freebsd.org) Date: Sun, 30 Nov 2025 11:20:08 -0500 From: Mark Johnston To: Adrian Chadd Cc: FreeBSD Net , freebsd-current Subject: Re: looking for testers for if_rge - RTL8125/8126/8127 ethernet driver 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: On Sat, Nov 22, 2025 at 06:16:28PM -0800, Adrian Chadd wrote: > hi! > > i've ported Kevin Lo's openbsd driver for these realtek chipsets to FreeBSD. > It works well enough for me to use on my laptop w/ RTL8125B / Killer E3000. > I'm now opening it up to others who are willing to build/run a kernel > module to test the driver out and report back. > > The driver source is at https://github.com/erikarn/if_rge_freebsd/ along > with build instructions. > > Please note that I'm only running this on -HEAD and I plan on landing it on > -HEAD before /maybe/ backporting it to stable/15 after the 15.0 release. > I've no idea if it compiles or runs on stable/15 or the 15.0 pre-release > images. If you're willing to give it a whirl then please do and report back > but I'm unlikely to add explicit earlier source tree support in this > repository (as again I'm going to land it in -HEAD.) > > Thanks! I tried this on my workstation running main, and it works fine so far: rge0: port 0xf000-0xf0ff mem 0xfcc00000-0xfcc0ffff,0xfcc10000-0xfcc13fff at device 0.0 on pci11 rge0@pci0:11:0:0: class=0x020000 rev=0x05 hdr=0x00 vendor=0x10ec device=0x8125 subvendor=0x1462 subdevice=0x7d77 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8125 2.5GbE Controller' class = network subclass = ethernet Thank you for working on this. From nobody Sun Nov 30 18:41:25 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 4dKG8l6PZZz6JcQr for ; Sun, 30 Nov 2025 18:41:43 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 4dKG8l3nB5z3Ycy for ; Sun, 30 Nov 2025 18:41:43 +0000 (UTC) (envelope-from spil.oss@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-595819064cdso4595095e87.0 for ; Sun, 30 Nov 2025 10:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764528096; x=1765132896; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=lT64Vc79vPZQ3+ciceq29cxK2681FeCQrD+5WA1/czQ=; b=JOaYB9ztkwyH1NnFI3GDxzA3QVslyZZa+FLNHSu6e2p2H90eXSzfHS6PBdSYrljhfn M6d4E9gadth/omsPOo2CJvuo3hbq8w6skoARWQqUvtHRUhkoW2o3p3ujE0zlBoJyKLEh TT3yhrV+y8wAcyBsDZr9SRMIbBkX+GOHkLj+wmUATmFtkCXRL4BLixd58/etU4255nMS j4XzcxNgNbTn/UUPCMGZAgBKwJJiqDjPnbIglNtsVgQAMgQxU9oEcprnV+jEwmjbsfRQ 1PvP0juhUWbv5U2QCDtzkNvtstb5B6B2+EYLZTIH+QF7v0SYHOyLrFpd8sMQ3UlN291D 75QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764528096; x=1765132896; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lT64Vc79vPZQ3+ciceq29cxK2681FeCQrD+5WA1/czQ=; b=bm+ivScNeoJUfypcvZzdJk6Ppa7PJ5iSmdE1g7YcIyYDT9xmCWu0PDvwMwzFbWsAQ2 3YeUuVbkJzyDcHKsphXoZO2F3UDy0QocacvOr6eWFbMN3ta3M8w1+NuSK7jjPVa8yE89 xd3Twh4TqMFNYRxCP211IuHhFxRJaNwaaxVA1cCIs/p+GzQc1XSlHR698XuL3yHti3cv mhaceRC6Kkgpw1J/d1ZoCDlEBHM1pdPaLmsUUi7dQqRPAHF0waIM9fzQNb7L1BT7N3Qd bmL0jaakYZsq5t0RK1iPnTrLs1p4kO3AgecxndMMPDGEGFt2apKD2F3cPwReEXSPf+wC cRvw== X-Forwarded-Encrypted: i=1; AJvYcCX6BVIKxlRvuz73kKpzL8AQHW7gV10c6dU99J0Scd38Pg0J0n4Pp08rkq1obGwYlfuP4kUZ/h/1YLoSDDrxcZ4=@freebsd.org X-Gm-Message-State: AOJu0YzIaOC6l+0WuIqwq5hWQpsmakCK0d9AGo3iSU0NotmEEDKQiZ4C 3KsC3QKJnaPUfqXzBxayJiKaPGcX5HIcK/P7WBjC2qYv3aoOuWaiNHIkzPAvzqFvFR+jnfxNqHU 8ARzTKmea0TYAb2lAuDmK8AKW+lWGKA== X-Gm-Gg: ASbGncszvk6oeNX7CxP/e5xnkYSY5M8QeOTpWvzrUL+yQUdwyPVHRaVLHz4D/rv1ARP JlDr8G2fgVHKU2idmw0PjoclBkMrR37b16iF/epMbqgzIoBfzy+6wTRjZcfpe+BaAH6C7FGgiwm Pwk1FS4+63yoM+UuDtm0VjZrRzYVD1LDNIGxbrpePI5pQ4WWaSTEKX6qy0W7QEOClCJf6YgqVQR fXAhH/59hqiKWtzjos7+FhCbC+4nVETERasCRDfqqGnVljfp/xpgzwV1xX3o/oixApgXC0kAR2T 0QsEe/CWTw7BUuyucBQUOBlP7mOk/SSrBC9wKe4= X-Google-Smtp-Source: AGHT+IHzwHx3vROTuqnOFIuEmCItENuxhiugzCgDDmuypDWn4e77qbYGc0EvyACo2Qy1xonp53x+Kz8lE2ECheReQSI= X-Received: by 2002:a05:6512:6d3:b0:594:37bc:f40c with SMTP id 2adb3069b0e04-596a3749dfcmr12339434e87.10.1764528095620; Sun, 30 Nov 2025 10:41:35 -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: Reply-To: spil.oss@gmail.com From: Spil Oss Date: Sun, 30 Nov 2025 19:41:25 +0100 X-Gm-Features: AWmQ_bm8bs5bQ-e6spUYnPiTHUHIbIOaOI5csoBGP2tXu8YBY8rQLYieSMjHxnk Message-ID: Subject: Re: looking for testers for if_rge - RTL8125/8126/8127 ethernet driver To: Mark Johnston Cc: Adrian Chadd , FreeBSD Net , 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)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dKG8l3nB5z3Ycy Hi, Turns out the realtek-re-kmod wasn't working out for me after all, machine started repeatedly crashing. Committed the port net/realtek-rge-kmod hoping to attract more testers. So far, works out great for me. GMKTek M5 Plus / AMD 5825U / Dual RTL8215 FreeBSD 15.0-RC4-p1 releng/15.0-n280991-c7ccd5b3f879 GENERIC amd64 Testing with 2 clients, both 100 parallel streams iperf3 bidirectional for 10 minutes did showed negligible load. rge0@pci0:1:0:0: class=3D0x020000 rev=3D0x05 hdr=3D0x00 vendor=3D0x1= 0ec device=3D0x8125 subvendor=3D0x10ec subdevice=3D0x8125 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8125 2.5GbE Controller' class =3D network subclass =3D ethernet rge1@pci0:2:0:0: class=3D0x020000 rev=3D0x05 hdr=3D0x00 vendor=3D0x1= 0ec device=3D0x8125 subvendor=3D0x10ec subdevice=3D0x8125 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8125 2.5GbE Controller' class =3D network subclass =3D ethernet Cheers, Bernard. On Sun, Nov 30, 2025 at 5:20=E2=80=AFPM Mark Johnston w= rote: > > On Sat, Nov 22, 2025 at 06:16:28PM -0800, Adrian Chadd wrote: > > hi! > > > > i've ported Kevin Lo's openbsd driver for these realtek chipsets to Fre= eBSD. > > It works well enough for me to use on my laptop w/ RTL8125B / Killer E3= 000. > > I'm now opening it up to others who are willing to build/run a kernel > > module to test the driver out and report back. > > > > The driver source is at https://github.com/erikarn/if_rge_freebsd/ alon= g > > with build instructions. > > > > Please note that I'm only running this on -HEAD and I plan on landing i= t on > > -HEAD before /maybe/ backporting it to stable/15 after the 15.0 release= . > > I've no idea if it compiles or runs on stable/15 or the 15.0 pre-releas= e > > images. If you're willing to give it a whirl then please do and report = back > > but I'm unlikely to add explicit earlier source tree support in this > > repository (as again I'm going to land it in -HEAD.) > > > > Thanks! > > I tried this on my workstation running main, and it works fine so far: > > rge0: port 0xf000-0xf0ff mem 0xfcc00000-0xfcc0ffff,0xfcc10000-0= xfcc13fff at device 0.0 on pci11 > > rge0@pci0:11:0:0: class=3D0x020000 rev=3D0x05 hdr=3D0x00 vendor=3D0= x10ec device=3D0x8125 subvendor=3D0x1462 subdevice=3D0x7d77 > vendor =3D 'Realtek Semiconductor Co., Ltd.' > device =3D 'RTL8125 2.5GbE Controller' > class =3D network > subclass =3D ethernet > > Thank you for working on this. > From nobody Sun Nov 30 18:48:38 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 4dKGK55RK4z6Jd1v for ; Sun, 30 Nov 2025 18:48:57 +0000 (UTC) (envelope-from brnrd@freebsd.org) Received: from smtp-out08.qsp.nl (smtp-out08.qsp.nl [193.254.214.172]) (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 "*.qsp.nl", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dKGK52xxDz3b1l for ; Sun, 30 Nov 2025 18:48:57 +0000 (UTC) (envelope-from brnrd@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 193.254.214.172 is neither permitted nor denied by domain of brnrd@freebsd.org) smtp.mailfrom=brnrd@freebsd.org Received: from 5921114a.static.cust.trined.nl (5921114a.static.cust.trined.nl [89.33.17.74]) by smtp02.qsp.nl (Postfix) with ESMTPSA id DF4E42FBA for ; Sun, 30 Nov 2025 19:48:50 +0100 (CET) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by 5921114a.static.cust.trined.nl (Postfix) with ESMTPSA id 4dKGJw4LHtzfH for ; Sun, 30 Nov 2025 18:48:48 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-5942a631c2dso5168405e87.2 for ; Sun, 30 Nov 2025 10:48:49 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVBLhtTAroPVPAoTh1zD75QHHbVPMRPrpE04SxhUTRMRqp12wxlOZCVnoc4ld/XuRksYlrfXukXezQGWAIxl34=@freebsd.org X-Gm-Message-State: AOJu0YxVFFe8OnZyoJ39Wud+Gd0zV3cWhmfy8mTT+9cQ8KzvMqjN+/KU sWf8oW798RACbS2os+MWAnIP39BDkcFWcWZdrLA6/cjilNXtHjxdlBvZ5TjlNKwkA7yFCYGIY9M zfbcpa73KOPh1cNBJlms+sNd5q4O7sA== X-Google-Smtp-Source: AGHT+IEE2tekcnmyWq7UCLuI8TvcqiKYzfc2LQPdOfvRQ8MWjGv/lr04UesVU0yr8EtuPKgmkTGUEWlbvVeNBpNBEtg= X-Received: by 2002:a05:6512:2207:b0:595:81e7:3daa with SMTP id 2adb3069b0e04-596a3ec084fmr11660698e87.27.1764528528266; Sun, 30 Nov 2025 10:48: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: In-Reply-To: From: Bernard Spil Date: Sun, 30 Nov 2025 19:48:38 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_blSeAYVMd6fI4ZviC2bCLZICuLktyfdsiCv7PiMnrAR_tTX1Zosr0AsmPk Message-ID: Subject: Re: looking for testers for if_rge - RTL8125/8126/8127 ethernet driver To: Adrian Chadd Cc: Florian Smeets , FreeBSD Net , current , Alex Dupre Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.960]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[brnrd]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.53:received]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4dKGK52xxDz3b1l Hi, Turns out the realtek-re-kmod wasn't working out for me after all, machine started repeatedly crashing. Committed the port net/realtek-rge-kmod hoping to attract more testers. So far, works out great for me. GMKTek M5 Plus / AMD 5825U / Dual RTL8215 FreeBSD 15.0-RC4-p1 releng/15.0-n280991-c7ccd5b3f879 GENERIC amd64 Testing with 2 clients, both 100 parallel streams iperf3 bidirectional for 10 minutes showed negligible load. rge0@pci0:1:0:0: class=3D0x020000 rev=3D0x05 hdr=3D0x00 vendor=3D0x1= 0ec device=3D0x8125 subvendor=3D0x10ec subdevice=3D0x8125 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8125 2.5GbE Controller' class =3D network subclass =3D ethernet rge1@pci0:2:0:0: class=3D0x020000 rev=3D0x05 hdr=3D0x00 vendor=3D0x1= 0ec device=3D0x8125 subvendor=3D0x10ec subdevice=3D0x8125 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8125 2.5GbE Controller' class =3D network subclass =3D ethernet Cheers, Bernard. On Sun, Nov 30, 2025 at 2:51=E2=80=AFPM Bernard Spil wr= ote: > > Hi all, > > Thanks to flo for notifying me that there's an alternative to > net/realtek-re-kmod. > > I've had crashes running realtek-re-kmod and realtek-re-kmod198 > before, none of the switches seemed to help. > After upgrading to from 14.3 to 15.0-RC4-p1, I thought I'd test again. > So far so good, no crashes. Generating load with iperf for 5 minutes > from 2 machines to the server works OK with the 1101.00 for now. > > Nice to have this if_rge in the back pocket when things don't work out > with 1101.00. Started porting it, find the patch at > https://brnrd.eu/bsd/patch-net_realtek-rge-kmod-20251129 > Seeing that this is supposed to land in base, I'm holding back on committ= ing it. > > Thanks all! Bernard (brnrd@) > > On Fri, Nov 28, 2025 at 5:48=E2=80=AFPM Adrian Chadd = wrote: > > > > On Thu, 27 Nov 2025 at 10:13, Florian Smeets wrote: > > > > > > On 23.11.25 03:16, Adrian Chadd wrote: > > > > hi! > > > > > > > > i've ported Kevin Lo's openbsd driver for these realtek chipsets to= FreeBSD. > > > > It works well enough for me to use on my laptop w/ RTL8125B / Kille= r E3000. > > > > I'm now opening it up to others who are willing to build/run a kern= el > > > > module to test the driver out and report back. > > > > > > > This is great. Finally, an in tree driver for these very common NICs. > > > The 1100.00 version of the net/realtek-re-kmod was just unreliable fo= r > > > me (constant hangs, no matter which options I turned off and on). I'v= e > > > only done light testing with the official 1101.00 driver. I was able = to > > > wedge it with less than a minute of iperf3, and the ifconfig down/up > > > dance that was able to revive the interface with 1100.00 was not able= to > > > recover the interface. > > > > > > I ran if_rge on my NAS and did some testing. I haven't had one hang w= ith > > > this driver, even after pounding the network for hours. That's a big > > > plus for me. Thanks. > > > > > > I was able to achieve close to 2.5Gb/s TX and close to 1Gb/s RX with > > > iperf3 --bidir. > > > > > > CPU usage appears to be substantially higher than with the official > > > Realtek driver. > > > > That's a good data point. > > > > > > > > [intr{irq59: rge0}] goes to around 50% of one core, and [kernel{rge0 > > > taskq thread}] hovers between 20-25% when running the above iperf3 te= sts. > > > > > > With the official 1101.00 driver, the only process using > 1% CPU is > > > this one [kernel{re0 taskq}] and it is around 10% with the test > > > mentioned above. > > > > I'll go dig into that a bit. It shouldn't be taking very much CPU to pr= ocess > > this number of packets; the bulk of the CPU should be used by the IP st= ack. > > > > I'll go run some profiling over the next few days and see if I can nail= down > > what I'm doing poorly. Hopefully it's something stupid on my end. ;-) > > > > > > > > -adrian > >