From nobody Mon Apr 21 01:25: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 4Zgnk85J5Zz5sgCX for ; Mon, 21 Apr 2025 01:25:36 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4Zgnk73LCfz3tRG for ; Mon, 21 Apr 2025 01:25:34 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=CSgOqMI2; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1745198718; bh=yMbtnEJ/kgLz5HU8MZz6ut43skRPJAPm0wQ6+KyaKd4=; h=Date:From:To:Subject; b=CSgOqMI2az2JBS6mDYhJzFXMHcbBhg9RSOcwLOKVb8nYtKPo/31G6uSIhpbmtyQVn SdJNb2mXZbCsdUdIAxVFvwhPL4wKCycSTY8eesiGUmZvMPkQ2ASs8Xuquc3H5ktoCM 8iQw33FbJdGfc2m3G7SAN+sv0pEvvwRLfh9ORCbdql9IVJrzn1i9DlqjBnW5sYllAG nKoMEc1Jkho5qQVxpfPDo0tF65QJXokXRKXrVIxrM5Xns+DWLJ1sRXOtul2izN3WhM DEq63Uce72L+pbBCxen13a2dC4fzl/yGNEf3PciCXCYarS4sq6jXQ5xVuBMzX6czj3 asdLPRSXH/09mKHwMQhRSDgdHAiLxF8saTlOygp2IFuz71duHOjgELZZlSHQpTMJiM l8/2VSV4j9d4t7u2SahgXgruyqxerSwqT2Uxiv2ijVZNj+XWxnpMzXTk8qGQbv19Xs fcKoijKF1WBkaKg7D/hkYppoxJlUfdkKfSH8jyZ/SJ4/lugo5hVhmx/YN45OMHbmEH Xi2n7KUj40pXfCKAj+uqwcTJhscNmt9yI5ynERu8p7y6h8JFfVyZ5jq3vvwJ96EVx0 eorXtX50V9jvRIYKbpWfo2RKl+uIhBht4kom+6FzLoansqIi4v4f6Xb/cx9aXc7YiK WYG1owDKbhoA1rYHjTyF3yAQ= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 369945A9371 for ; Mon, 21 Apr 2025 04:25:18 +0300 (EEST) Date: Mon, 21 Apr 2025 04:25:16 +0300 From: Sulev-Madis Silber To: freebsd-current Subject: zfs (?) issues? User-Agent: K-9 Mail for Android Message-ID: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> 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-Spamd-Result: default: False [2.26 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-0.99)[-0.986]; NEURAL_SPAM_MEDIUM(0.98)[0.975]; NEURAL_HAM_SHORT(-0.93)[-0.926]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4Zgnk73LCfz3tRG X-Spamd-Bar: ++ i have long running issue in my 13=2E4 box (amd64) others don't get it at all and only suggest adding more than 4g ram it manifests as some mmap or other problems i don't really get basically unrestricted git consumes all the memory=2E i had to turn watchd= og on because something a git pull on ports tree causes kernel to take 100%= of ram=2E it keeps killing userland off until it's just kernel running the= re happily=2E it never panics and killing off userland obviously makes the = problem disappear and nothing will do any fs operations anymore dovecot without tuning or with some tuning tended to do this too what is it? now i noticed another issue=2E if i happen to do too many src git pulls in= a row, they never actually "pull" anything=2E and / or clean my obj tree o= ut=2E i can't run buildworld anymore=2E it gives vague errors if i wait a little before starting buildworld, it always works what could possibly happening here? the way the buildworld fails means the= re's serious issue with fs=2E and how could it be fixed with waiting? it me= ans that some fs operations are still going on in background i have no idea what's happening here=2E zfs doesn't report any issues=2E n= or do storage=2E nothing was killed with out of memory but arc usage someho= w increased a lot=2E and it's compression ratio went weirdly high, like ~22= :1 or so i don't know if it's acceptable zfs behaviour if it runs low on memory or = not=2E how to test it=2E etc=2E and if this is fixed on 14, on stable, or o= n current=2E i don't have enough hw to test it on all i have done other stuff on that box that might also improper for amoung of= ram i have there but then it's just slow, nothing fails like this unsure how this could be fixed or tuned or something else=2E or why does i= t behave like this=2E as opposed to usual low resource issues that just mea= n you need more time i mean it would be easy to add huge amounts of ram but people could also w= ant to use zfs in slightly less powerful embedded systems where lack of pow= er is expected but weird fails maybe not so is this a bug? a feature? something fixed? something that can't be fixe= d? what could be acceptable ram size? 8g? 16g? and why can't it just tune e= verything down and become slower as expected i tried to look up on any openzfs related bugs but zfs is huge and i'm not= fs expert either i also don't know what happens while i wait=2E it doesn't show any serious= io load=2E no cpu is taken=2E load is down=2E system is responsible it all feels like bug still i have wondered if this is second hand hw acting up but i checked and test= ed it as best as i could and why would it only bug out when i try more comp= lex things on zfs? i'm curious about using zfs on super low memory systems too, because it of= fers certain features=2E maybe we could fix this if whole issue is ram=2E o= r if it's elsewhere, maybe that too i don't know what to think of this all=2E esp the last issue=2E i'm not re= ally alone here with earlier issues but unsure From nobody Mon Apr 21 07:23: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 4Zgxg84v9Fz5t5WB for ; Mon, 21 Apr 2025 07:23:32 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (3072 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zgxg74NnKz3wTW for ; Mon, 21 Apr 2025 07:23:31 +0000 (UTC) (envelope-from garyj@gmx.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1745220209; x=1745825009; i=garyj@gmx.de; bh=UWArhNRGf9ePQE+PXlgeGczs1shRrWoC64I/nB7B5bM=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:Message-ID:In-Reply-To: References:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=ZiCkwRAr0ZrVTvRFxfGNDiJZgyJWId/LuQpCJGNuwvmv5EheozUZbst78z7g4QG8 oG3SqzTkLuZZKo2c4pgvfLVb09COIq64MbE+C61ggc6UqrwqQgg0BqvNngJwf1M3j ogMbOB6t7V7mgmH7NoWvXforLMky9wDnhIkvpmzNOC2c7/NIMENze5DgrKXrbL4ul 1MyJTzzyFhStLuKkRDwrBKLMb48xzH3B1M71LAXHLt4DTMtoSqqlYIGpWZilf0k07 9uakxrOW9t+nmC4nzCbzLsrh31YIffGgJjvOK312tR1uSsgO4K0iL5178HwMxllpr IIT1ADs+TsQkRXBWkw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ernst.home ([91.59.228.125]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MgNcz-1ulaxj3YkB-00jzV0; Mon, 21 Apr 2025 09:23:28 +0200 Date: Mon, 21 Apr 2025 07:23:01 +0000 From: Gary Jennejohn To: Chris Cc: freebsd-current Subject: Re: New kernel =?ISO-8859-1?B?ZG9lc24/dA==?= recognize ufs gpt root filesystem Message-ID: <20250421092301.724f623f@ernst.home> In-Reply-To: <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> <86bjsr5jv8.fsf@ltc.des.dev> <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.20.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Y2n1s8YOZgLMJvMZynAMpCCndOi9vA8i9hiy5aM22Zw8MEM/ybZ 8gyYfSrDgGZGuLg0J/blDtA+byqSdTTXG1Mvg1pdSuXbbRvb/Ldbi9SERdiUJ68aCyzdb1+ eGJMaG/Cs6dgnaJ1F52zOL8benVF0RC1TVnD8QiMiN4yA+8sfLDDFBkq84jp05f6rmYt07A rvboMn183ip/bXy/Sy6xA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:D+GJNbDgGVo=;UEjlRvaDddCbp0DKp5XZb79FFMF yB7zcegileBThVJ4kLw0u3JHn6h83KsKrDxLpKEGcPWC3gtjOTJ81axYzwxpaxefoADyllEyG lo3339vWJ0PMyglvrp4bAgPZRsmi/kU1zfcjcZdAIV21lSvACQ9ZyQhKEnc+ZDJA2QOd8k4t7 rVbZ8Wz4C/rd0noUSwUzpm59O4X6EnUzmNOmcTVVqo4IpLj+HCs5RT2peKGrchyri9U5VVla4 jsLD/GkywDYJxJkis2xJh1n3VxJRmU9S3mygrHNC2X5EWe/LljAZlLvl3IUC8NqJ939qJCQMJ kZCXRRXPztAJtmsHcdCnNAGyFUOoBMn0sOx5vjcnEhrJCUWuF1YC7HazABacdMukcy97nC2XY D//rzCvJ8cIquSBD8kKBW5yhmhgz2YMlPby06SrmixVpfWgRsERHZy4LkPoJyITL6lqd0lMUl Z1BBK1/WS5PjnyqPQPk9Jx9RFnO4j1Y4WgwEMGt2BTnZQnTzsALCEaqlqUpvoqG1bv1vjrs7s ik7YnBJoRFmU1pDwmzW32ZhFfd0qmE0FHSruxk3g0sbfMZFpIVppcTY+Mr/tMooUI0jSv2qoP BAsjj5PHk+lXtpQ7iNcwsKJETC54rTvixKwAo7bCQZu28kVe1+P1/sFySzTEPHp9WkqZxYkAq qXEmUmbU9nnE2Vx/fK7SAf57WpPHWeiqFTWERjkXsVDnmndRRzuR/lsQfzhijYdm2LB75+i4G RFgNw0E87/VtZf3Hb1hYx2CrSUG2F4o0W0bQFM3CzoQSMnKo77yBCxadUQukpD0YB1ehDBpSV Dye6i0ChDkwlR+7ToZ2yc/dBTO0Tc6hqJl03D0+T7PBFXR9LO1RaAMP1lAXKUGnooYRPSwH4L I3eZMmASOqpR7fLQq01svRYc5z/cx/ZRnGjJzBE+ZlGPAohEzFaVn/1XhRPiSMXaqLtZfsX4o M1oEvVFx2IUR8ycMOfjEfKvXsHX3tTJcwW+eakV1SdXVBwqgBil1w2cNvGxgnObpGV3VUIgBW MF+KJJPQMqNVvQd/q1L7s6qS5Jv0DIu+wsVlGSjQDXw1s+O1uwYaMeEweiCFEsZnahS7lH0fM 90e5f1Q6yLUwLKC9aK+C6DZONMU7Z5c6TIsvlEQTETOf7yf0PWZ89frPfsTL+Fuqhn9d+jdM0 qPMynpwGyJbUj6+T2GHtMQkdREYOFxe+Jz2PC9I6DGK9w6uQLzthY8lqstra8i+gxWbr4g6MA oMi8EO/nsEutgnbpMt0qVNPxr7Radw0OTUN99c4yjwDXdTp4AXsWEa1GmgodyAozOigBhmIK7 ZVJJHzsqKarB4YODgazjHahuULDPhtIV9RHYTxzqccuCo+ugYoDWtwHX0xzNxk0QdZzAYNua+ LtXKFOV5CMUdgS0VCILy9GM2aTGc7f2ru6lwmCVqbLpWn3T3mWUfnnFezmQXczCpiWqbCCQO+ /KRR3uubHbB9Dt6EXBRHWwjxHunq0q0CMa8r11bHjDNCzUI23H9trK17uvpfApOx/2P2TPWu1 hCQnsT7bmKv+bM4++9XXi+H2eo6xEEPI2tEJagip/q5X2Agg7KzDa1GO+dECrMdkH1ApKUWRX zGWpkdz+jUiwDVmHTLsRSjBx5MyY7L92WEbgXvw3MBRM9O5lG8XrY3ZH+ibDtd6b7K5dfADKE 2Csd1AY9jiU/8J3evxGXic9Nhj8PfgKH00AUl9xyd+RgvFz0Hz0TP0sHiaSlSlqKN81gBR8MZ UZd0C0VY9wN9d5J5xVc5RnwBlB0eBE8Juhur7E7mQtMGKiCoXNVysRGMHso28uwFKFHMSs0kL JNIegE/U8vZhvnxz5WdbU1hStCApqGwmMp7gtbjUZw4l5+YEugs+RAmfjNE7UldRpUHhDfDVt Io5ztFUO5MekCJew8Kk0b6IVBqv29Of2Qy5Cnbp+k4zk5O6A+bw20ouUIir62ZMQlzQ85zP/W eRrXNaeVI58+cpAegj15Fnx6fVfJh2px7t7f8gPW0kWNiUcEgYViuMIPFMu5w3Z1Xxy0LNX/k l4/yyLk/HNkFDq2g4MplVOwV2gfq99zUt47J8bqMluMrd0wxLVDtqRZfIUWDpBHkjQfrfGsi5 NKDykZSR1Usru2GTsVZK10FPAMKyUg/EexrP+tLQyRsjTPTzln06g+O4S7zLw6WEDsqTo5lue IhlHwxB+0kSrPKo8HrTdSTp/KqnQOJLlp2wE3NtcnWHO7EYUKykvTK+wMAt9/sJQNBjq8D5YE HgZku8ooIB2/u7OU2bcp4biHaWDKDUJpzcwiR+X6FnF/Om7zDsAPQ4XyK5NmvSIih4aN4uztL FirWFutfsbzeQBMODfozdEaxQv7FQgZappP2PXoQXmZltf5CiTyXjLyq7zqkON6WDCp5GvP32 1SNQjY4VaxLwnNd2aylsDEpDikCETw/eRLI3jOp3fw4fLvUrR3dp9zLlojBPPPBN3Cd3HA9lf +lx1lTTaUoNnrA+zYcREki4WAqF/j/aTfd7PtAnuTS6VxSIg38Ax2I0sDr2ZscRA68f3p5Ifj FctMs0JSAgzQF0xIjs/1gwcBmKzwlgWRF+4BJQjlaEHzyujoK2oCXkL1cBA+VFkVqXTdDq2oo juedCI1YHS26z0mgAhxHHx7OzXLDGJoGWQce5QxqBPl20bPyNh+UZfSwKq1TLpJ+oIvWC4gaJ YtpJ+LiXjl//acedBbzKHKP6moAuN7Wn8psU/VBY1Hq7atcfQ92Cr+cHVgAEqE87+IXQxkd2W THPzy/Opo9uNUIdiIVLr6MPTaTE7KEUzQfr6ybB+l7qEV+x2pY2rxMOxAX1iQcdACJ62eYXTE zcKV+sg3GjdKSHRlW5Q5KR8uH+afqkapaTH4Bmy7q25i/9hAlzx5Clrq54bqlY5D35wwBVYsT Ju1pNsbGgKm4J6/Rzn5aIW5OXP5A9NGr/JzomQp1YpZKUZbNgaohjH73ZC1Ao9Wle1XaqqgsY TVVrgDIoRYq5mMEufZnZz8nGkOkTqbbLs+ksOlu7dzNpZ1iLGxsy+p3K5zVTXWHHHR9nkn6Fi Cs3zITDkqgIVp91P666QKw= X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] X-Rspamd-Queue-Id: 4Zgxg74NnKz3wTW X-Spamd-Bar: ---- On Sun, 20 Apr 2025 12:19:45 -0700 Chris wrote: > On 2025-04-20 01:15, Dag-Erling Sm=F8rgrav wrote: > > Chris writes: =20 > >> Warner Losh writes: =20 > >> > Maybe this is a custom kernel without the label code. =20 > >> It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But > >> I'm using the same kernconf as before. Was label removed from generic > >> in the last 11 mos.? =20 > Thanks for your reply! > >=20 > > Please share: > >=20 > > - The output of the `what` command on your old (working) kernel =20 > FreeBSD 15.0-CURRENT #1 main-n270118-94b09d388b81-dirty: Mon May 13 12:5= 7:41=20 > PDT 2024 >=20 > > - The output of the `what` command on your new (failing) kernel =20 > FreeBSD 15.0-CURRENT #0 main-n276516-65d8491719bb: Sat Apr 19 17:41:06 P= DT=20 > 2025 >=20 > > - The kernel configuration file you used to build the new kernel =20 > https://bitpit.us/kern/LENOIP15ND-NEW >=20 > here's the old kernconf: > https://bitpit.us/kern/LENOIP15ND-OLD >=20 > and here's a convenient diff of them: > https://bitpit.us/kern/LENODIFF >=20 Removing ctl might be a problem since it supports: /sys/conf/files:cam/ctl/ctl_nvme_all.c /sys/conf/files:cam/ctl/ctl_nvme_cmd_table.c and you have nvme in your kernel config files. But I'm not sure about that since I don't have nvme in my config file. > > - The contents of `/var/run/dmesg.boot` after booting the old kernel = =20 > https://bitpit.us/kern/dmesg.boot >=20 A diff of the new and old /var/run/dmesg.boot files might be useful. [SNIP] =2D-=20 Gary Jennejohn From nobody Mon Apr 21 08:00:13 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZgyTX3kqnz5t813 for ; Mon, 21 Apr 2025 08:00:16 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZgyTX2SyBz3HDV; Mon, 21 Apr 2025 08:00:16 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745222416; 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=uKsiVpEqw1fpH1OIpurqJsQc1/0Xy1Eg3qYmYHgAbKE=; b=cPtCLlRGLPSyEwb03gyKIQujMGN3TuSUctTu9OeBsd3m6yt/im6dr3hJX/zv/bIoQAONOr Hkpt5SlmJI22h4vNsQpGL+Zi0hAMEHLoNQSxXQOZoB1tmj1kIGaPzVkGQx6iVAE7xwc3a6 ZLZuITPQCcxDI7Dr0lIDjW8wOzybdcqc46ybewIjfCefg8ErQQfZ8teI89l9c2IJg4+9S0 M753bJQ6j4UUWFAprsi+o/LeccyjUQQDboNJQrtP7AaF/wjXOy+hheQLy8a+3mcY0XVWGc 4aigQ/PwF1CKYug4s0Fbi7NVp4KEfwsWO7kV3ppM3VaJj+jDX9/G150jCEb8XQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745222416; a=rsa-sha256; cv=none; b=QiBp43pcdOnzEU3O9DIkynsIDAS0AX8hlH1gYdKy3HtCZqypHYVhunz9vk0kWVitQQ0zm5 KD3vYo/NGcEp9cS7ruzb6eRHl/Gb1OPb7BQFXzKb+7DWI56l6e/n+M9OkwsyxKm4YiLmnT kY0MksqjJfkBO7pdURgylKneaj1ZNxgN/qcxxHe6duefvN+syKNzaR/WYhplgidc6RrRBc YPR4ugd8QXH/APG82ecSj7vi/GFy/yHo4UnyCvAr3x5JEEJjAcR14a0tFI6SdAX/2ZU30R wbnEGs/aEpt2lqmkR79I7pyE6bcA3vV/Eef077r1HiAv41Zamlks3ZtiU3BfEw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745222416; 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=uKsiVpEqw1fpH1OIpurqJsQc1/0Xy1Eg3qYmYHgAbKE=; b=jD9EtuN40y1aCrUREFGbCOay7gcNR9oZHque0EAI37NFKqeGPm/RbpAMxrzazB4Uz01dgT rL23e7EVbtYMZojM8HTp2h5BwDDzvCe13PsXL+/cn8JXqpyF0uw9rf1Rb5jWHenVx72U2q thb8h4g0Xwnn2BOY/DHrGoaf2TUpFNpeoML4//YWLo2vRzYVsnxk9Nlq6gSgwl/u3jaXnM Tud/rwqmB207REJFa7PCLQM0e890JIlUrWbkFa+g+wFe3jjGCFnJLrfbMPVEMCXTf0ySs0 rAba9D8lutBaRcgq5r7gQxRfh9pPGVN4LAYS0pOo4akG33UveSXEfWIm9d6jbw== 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 4ZgyTW5wNbzCv2; Mon, 21 Apr 2025 08:00:15 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 21 Apr 2025 01:00:13 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: April 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 April 2025 stabilization week started with FreeBSD/main at main-n276625-d4763484f911, which was tagged as main-stabweek-2025-Apr. 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-Apr 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-Apr If you want to use only the official FreeBSD repo, then update to the revision: git pull git checkout d4763484f911 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 Apr 21 13:42:49 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zh6534vcYz5tW9h for ; Mon, 21 Apr 2025 13:43:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 4Zh6530hftz4LGv for ; Mon, 21 Apr 2025 13:43:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2ff85fec403so4464059a91.1 for ; Mon, 21 Apr 2025 06:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1745242981; x=1745847781; 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=2DesOWoebOVe7y9oOTm2N1B4YRcBo5EWu9mnMb2iTPk=; b=tUdynWs4QnGJ7SBAc+THENeNHLnsMzPiK/Idmt5JCi9BnDW20uXdowftBVO6EePtMP H1TbjxHihyejpSvy6w6YOG4fR58vRbUiUwZnBIfvHxVlAuRm5lmIb2FVb1OGGXjM6mYA 2lBsX+1vGR6UcogMe4vsebRwNGocCsasc/sTgWijwS3CEPYCOl4tNQX9NoxqbA6YabJB 3PhWLFjZgtqZQ29qXATZQXN/0utQnn6ZCmswOBbojPDcwcEB+KQDxQDkanhTCi+fK2hb +ZM4iORH6SSQZhBI+ZnzFbAMxz+UAlbLh0Wx6qBrDVJOk2fEFuP1zfXCDqbeQHOf7h/h fWJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745242981; x=1745847781; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2DesOWoebOVe7y9oOTm2N1B4YRcBo5EWu9mnMb2iTPk=; b=N1AB1OnQPSaserJy+khOVIrckj4IRlk6s7zQCgsSwwREl8WjHSiJ08XJ1MXHapWM2x wEt75qOn0M2EfRSKY1ep6zs1ymILThd71D5JziUjulfX9yoAzi9hmYGEFcTRHMpUObt5 OZ5KjGKKwmr9U5EGsdMh+vMnzSPArgvHcjFQv4eY2Qxy1JD5AuHNyNNbqXEjeFzjrvVN 5W8R4Zqb1yAvp+kcXiAAc1298aMnC6+Jzn5dxMaRRKITVhcA4y/iMJgHfnzFNgGpp4OA Z9ruGzJj7ef1EUJrLwYCSGtEhA9xtfw8BDVFn7GvOeY+3CdYttpw7EFbXDt3kSgy7Z/I PICA== X-Forwarded-Encrypted: i=1; AJvYcCViJPgUb8O0RreX5VFdQQmUnypPtFdDmnPREQd7RC1dB7LjMyIzmWV+xhGrv/+Nxc02D9rb0nidtBAWWGWtDb0=@freebsd.org X-Gm-Message-State: AOJu0Yzrlu64dvC8fe+ny4lnZgvazkbWoPja9xtRyEA57GSjNcKMm+nH hjgCXNrrz+HRsgijM0tVhNysjSe/v1/MT6y5b54MnrJVBkMPLeUiXdMXduNZM45AyhOa8wJDidY ZjzfbOthDIz5E2Gg2x/OpHs+hbD2NDSaruXkldg== X-Gm-Gg: ASbGncsrMzxL6hrzYMEDr/frpVbsMwPoyrmMohB7yvtjcxwy8XxIRBVA1Hb/nFbZNqu 6NgYCrTfO9ZSLPRS7nn77yRfp9Z4axNJURaISrPjFIQzz3nnVUHFq2ufhsB0xkeE4FLSXcRieTd MnoeJALxyIILH+kc57PHdQxaEdCNOtZC/m7jS+a4ToXyTABZn/zCA= X-Google-Smtp-Source: AGHT+IHjOmUE+HR5r1qE0QBdhkHrOf8CbI6sgNEWJYoW8Z/AUd0v9sfD6MUj/Fmb9mM7CqO0E/2qA/x1lY/rTZnsvgU= X-Received: by 2002:a17:90b:3808:b0:2fa:4926:d18d with SMTP id 98e67ed59e1d1-30879c02a9dmr17780027a91.13.1745242981561; Mon, 21 Apr 2025 06:43:01 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> <86bjsr5jv8.fsf@ltc.des.dev> <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> <20250421092301.724f623f@ernst.home> In-Reply-To: <20250421092301.724f623f@ernst.home> From: Warner Losh Date: Mon, 21 Apr 2025 07:42:49 -0600 X-Gm-Features: ATxdqUHKE8FtQrbLnkdLO-pt5suEaqyLp3DVRQujJs4Kkl2JguUHD-65MYs3tPM Message-ID: Subject: Re: New kernel doesn?t recognize ufs gpt root filesystem To: garyj@gmx.de Cc: Chris , freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Zh6530hftz4LGv X-Spamd-Bar: ---- Put 'da' back in. I'm pretty sure it's not optional. Well, maybe it is optional, but you'll need nda if you do that and the kernel config doesn't have that. While you have nvd, the default is to prefer nda to nvd, even when nda isn't in the kernel (so more like an either or choice than a bidding choice: CAM device nodes don't have a bidding process to them, and even if they did nvd vs nda crosses between CAM and non-CAM and there's just no good way to cope). Warner On Mon, Apr 21, 2025 at 1:23=E2=80=AFAM Gary Jennejohn wrote= : > > On Sun, 20 Apr 2025 12:19:45 -0700 > Chris wrote: > > > On 2025-04-20 01:15, Dag-Erling Sm=C3=B8rgrav wrote: > > > Chris writes: > > >> Warner Losh writes: > > >> > Maybe this is a custom kernel without the label code. > > >> It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But > > >> I'm using the same kernconf as before. Was label removed from generi= c > > >> in the last 11 mos.? > > Thanks for your reply! > > > > > > Please share: > > > > > > - The output of the `what` command on your old (working) kernel > > FreeBSD 15.0-CURRENT #1 main-n270118-94b09d388b81-dirty: Mon May 13 12:= 57:41 > > PDT 2024 > > > > > - The output of the `what` command on your new (failing) kernel > > FreeBSD 15.0-CURRENT #0 main-n276516-65d8491719bb: Sat Apr 19 17:41:06 = PDT > > 2025 > > > > > - The kernel configuration file you used to build the new kernel > > https://bitpit.us/kern/LENOIP15ND-NEW > > > > here's the old kernconf: > > https://bitpit.us/kern/LENOIP15ND-OLD > > > > and here's a convenient diff of them: > > https://bitpit.us/kern/LENODIFF > > > > Removing ctl might be a problem since it supports: > /sys/conf/files:cam/ctl/ctl_nvme_all.c > /sys/conf/files:cam/ctl/ctl_nvme_cmd_table.c > and you have nvme in your kernel config files. > > But I'm not sure about that since I don't have nvme in my config file. > > > > - The contents of `/var/run/dmesg.boot` after booting the old kernel > > https://bitpit.us/kern/dmesg.boot > > > > A diff of the new and old /var/run/dmesg.boot files might be useful. > > [SNIP] > > -- > Gary Jennejohn > From nobody Mon Apr 21 14:22:57 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zh6zM270Bz5tXcN for ; Mon, 21 Apr 2025 14:23:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 4Zh6zL46nmz3SRC for ; Mon, 21 Apr 2025 14:23:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-afc857702d1so3451373a12.3 for ; Mon, 21 Apr 2025 07:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1745245389; x=1745850189; 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=/FUHxiFXRJAkIibfAvYFh7JqC3g6fxClNMNgGctFV+o=; b=MppaXgNv2YhhfMGXI9dqLk9TN8KQRb6c/EkaCRGXdSTd95yqSGsvmkBPmKBFbaB2Rq pPZtDh9GI8Lni1wjB/iRWhrRpwrkyGdLTWFquahK40FGXswhCgM143UpjLsGmWNWpTVY fujI7nI5mbj4oRrf1NqANdzxXjf7hpwFixr/WJbsAp7KfhF/0RIlfGseuo6n4wMqReRx 6xHPB8oZxUbONkvRWYOSXd/ugi35KBTVfdrCXPvliTOYOYCHTz2cC9tc+to9ZrjIBFD/ WrHw5Y9ut6xXffJwILtTo3mimAiKkliY0I7bQlT4OGcqI/8l/+IDo3suPsmmIYUPbzqA Y2qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745245389; x=1745850189; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/FUHxiFXRJAkIibfAvYFh7JqC3g6fxClNMNgGctFV+o=; b=dvLSHKM4IPqBu+Q4kfCknayHGdGlYS9ks7HNHxbhY8ewf4UaPNBJ+vcWIzXl4Dw4uZ Ok5dfeMEjiZLnVnq+hW44AIZdrfm+pXvRblDhAxj/iIttlA2/Ox6UfK2b1O9omfEhYwC XXL6PPpzBVqI+kFlsqnGBsca0YmEwI5Uo4EolgtYl+GFZLMQviJZpfo3BU4EtxxuzDHV dfn/nalJ64iQ0rDONEJgC477wrXbP7DXtBidKlnnGKi3DJ8bucAi8l3+SEH8Ti4O8bzo c/UoYUPwWKAeDiN4nPC0e2Rr1Sqrn4Kengbfvc5p3TQVqtLAGSmtFFZiigFhbgH03JS4 noew== X-Gm-Message-State: AOJu0YxWmfGJDxhhgWYcwG0rF6R7JEzrzp8NneePtrcXF+h9TCzSJX8s xQkapio7EX0xImDQwck2h531yZCJjSaryXWQV9kDdw95TdQGB6kn60SEBzVi8k0DatW2exVkjFJ nZMTR/+Q2xjFdEK0+zl0F9MDpB352WDmypNDHQtCzS9TpvQGO X-Gm-Gg: ASbGncsEdwKVqLdF2TFL+rlWjKWlREpw/i6hSlpg6Vo/kq8ZBPcQI2eN13VahAAp+NR ixDXfcwlLkPf7Ovkt4QWj+55zyC5UbKT6iHP9tE06wyxLm8a0ZOOhxifLs9/lO2oDaQb8UGzqWc Q4F4WTc6ETr+CksHZn0PDxAL5/0IySNJgJFRNmYQY3lPKXbK7rZFM= X-Google-Smtp-Source: AGHT+IEdwlRK3VAMEi7NnM3lzudaYmqlgKIIzk3SzH89Yr6XXd7bOFph1qxWPBH00Ld4aEzw69RXBQXi/hdudzVQPmw= X-Received: by 2002:a17:90b:2f48:b0:2ee:ee77:2263 with SMTP id 98e67ed59e1d1-3087bb418dfmr19239202a91.7.1745245388687; Mon, 21 Apr 2025 07:23:08 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 21 Apr 2025 08:22:57 -0600 X-Gm-Features: ATxdqUG8CFABlEt0ZWwFSwMC_tbmu7yY2o9kSAqu4hg3jEvAPZK2i3CsTKRxOLg Message-ID: Subject: Re: April 2025 stabilization week To: Gleb Smirnoff Cc: freebsd-current@freebsd.org, src-committers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Zh6zL46nmz3SRC X-Spamd-Bar: ---- Please note: Gleb is on vacation this week, so I'll be coordinating stab-week this time. Please be sure to cc me on any problems you encounter. Warner On Mon, Apr 21, 2025 at 2:00=E2=80=AFAM Gleb Smirnoff = wrote: > > Hi FreeBSD/main users & developers: > > This is an automated email to inform you that the April 2025 stabilizatio= n week > started with FreeBSD/main at main-n276625-d4763484f911, which was tagged = as > main-stabweek-2025-Apr. > > 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-Apr has been published at Gleb Smirnoff's gith= ub 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-Apr > > If you want to use only the official FreeBSD repo, then update to > the revision: > > git pull > git checkout d4763484f911 > > Developers are encouraged to avoid pushing new features to FreeBSD/main d= uring > 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 From nobody Mon Apr 21 16:01: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 4Zh99D4kD6z5sgGl for ; Mon, 21 Apr 2025 16:01:52 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zh99D14Ydz3Rhv for ; Mon, 21 Apr 2025 16:01:52 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53LG1cNv048928; Mon, 21 Apr 2025 09:01:45 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1745251305; x=1745251905; r=y; bh=8/WOzySvhBL8Pj/2z+ksOs4MJFMLvIWPAfREQXt6xks=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=sOeTp4tx1MoEleQyHf1ud8aU8vIwNe0fm3Fr91mqH3bIHrxLIJq3rnwIiVxyP1Gm1 mQi2ydXQ7nfLRC0V5Bh4CsWroKDQNDM3LdK1eXZm928IOm555rVGDwdRiyuVGr+b6h MxkmKiDgPzzlUS3tR8yCI4N9abzDp65qCOLNzUtvrfsNdVafEGAiIf0l/nS3s9CG3B xeNG1MmVTCVTKU69rXq0q7QL70Tduxl7HujRLvraht7/aacHT5CKz13qq7XgD3A/xQ mucaLtQxCzwnG4eWlJSgezVRbe59/Xa7ikNRvsJwKn43TvijQ8TwDCazMD7IzUfVBG z8jD8mHkziunA== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Mon, 21 Apr 2025 09:01:38 -0700 From: Chris To: garyj@gmx.de Cc: freebsd-current Subject: Re: New kernel doesn?t recognize ufs gpt root filesystem In-Reply-To: <20250421092301.724f623f@ernst.home> References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> <86bjsr5jv8.fsf@ltc.des.dev> <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> <20250421092301.724f623f@ernst.home> User-Agent: UDNSMS/17.0 Message-ID: <7fdc20653ac8aa60dca6859ca81abbcd@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_985cea4ff5f8bb7aed9812640e440bf8" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4Zh99D14Ydz3Rhv X-Spamd-Bar: ---- --=_985cea4ff5f8bb7aed9812640e440bf8 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-04-21 00:23, Gary Jennejohn wrote: > On Sun, 20 Apr 2025 12:19:45 -0700 > Chris wrote: > >> On 2025-04-20 01:15, Dag-Erling Smørgrav wrote: >> > Chris writes: >> >> Warner Losh writes: >> >> > Maybe this is a custom kernel without the label code. >> >> It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But >> >> I'm using the same kernconf as before. Was label removed from generic >> >> in the last 11 mos.? >> Thanks for your reply! >> > >> > Please share: >> > >> > - The output of the `what` command on your old (working) kernel >> FreeBSD 15.0-CURRENT #1 main-n270118-94b09d388b81-dirty: Mon May 13 >> 12:57:41 >> PDT 2024 >> >> > - The output of the `what` command on your new (failing) kernel >> FreeBSD 15.0-CURRENT #0 main-n276516-65d8491719bb: Sat Apr 19 17:41:06 PDT >> 2025 >> >> > - The kernel configuration file you used to build the new kernel >> https://bitpit.us/kern/LENOIP15ND-NEW >> >> here's the old kernconf: >> https://bitpit.us/kern/LENOIP15ND-OLD >> >> and here's a convenient diff of them: >> https://bitpit.us/kern/LENODIFF >> > > Removing ctl might be a problem since it supports: > /sys/conf/files:cam/ctl/ctl_nvme_all.c > /sys/conf/files:cam/ctl/ctl_nvme_cmd_table.c > and you have nvme in your kernel config files. > > But I'm not sure about that since I don't have nvme in my config file. > >> > - The contents of `/var/run/dmesg.boot` after booting the old kernel >> https://bitpit.us/kern/dmesg.boot >> > > A diff of the new and old /var/run/dmesg.boot files might be useful. Indeed. But I'm not sure how I might obtain one. Since the new kernel can't find a drive to write to. :) I guess I could take a movie. But that'd be hell to transcribe. Any way to redirect the console to a remote host without having much of a system yet available? Thanks for the hint, Gary. --Chris > > [SNIP] -- sent from hardware written from and running on FreeBSD --=_985cea4ff5f8bb7aed9812640e440bf8 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_985cea4ff5f8bb7aed9812640e440bf8-- From nobody Mon Apr 21 16:29: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 4Zh9nh2wqMz5sjLk for ; Mon, 21 Apr 2025 16:30:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 4Zh9nh0Gnxz3hcD for ; Mon, 21 Apr 2025 16:30:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52b.google.com with SMTP id 41be03b00d2f7-ae727e87c26so2760417a12.0 for ; Mon, 21 Apr 2025 09:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1745252998; x=1745857798; 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=+cI+Gv2Lb0H/2JobKgZCCUiRlMmStasOgD4DPV28zR0=; b=RyQFDqXkbP25mw850VlolVbj2pf1X/4AZwp5yT2JT5GJWRl9QMdEqlKPWegnJk7xs+ dNWj1jWSmnkhkIqgXr950AM1D45gKZxlrrrQv0GtiF1wY1rlEQOWydIc8EG4y5dtYOWa 2FHpkhZBDwowGj6kgNEB98nBtPXXpFZ7plUB/cV8zE6rBUHVwoQg2VNtps1PYP7/ge7k FU5kvEQqzhsUdEtjrmLaqQZB+j05QFiLVd2MmRTLqESGJHAAzd3o5Lv4NH7zzNcQZKSX Wql5c0a6/RlouF2HKY0aJFTE9gh2ax0xyaW2MSy2h3lAsDbwYvxdkwAEXS6TMCyFvXoN yorQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745252998; x=1745857798; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+cI+Gv2Lb0H/2JobKgZCCUiRlMmStasOgD4DPV28zR0=; b=JHqgrSvPglymYey+LXF2Pn8o0SFEL73Ut17wmRMCJ1+oIPaCF1vyD7zafU3fhXVoPe CJ5eQjmVIfkrAl5Fo/kPElcjxy6Df6iAOxDjPMHwm9KOq66wzpw5QTPfxDwES8WoWbXK +U9hTIwkxWMkEY1vG+l2Ak3+hb7vKX4Sl0m3e9qNNXN26+OeBtI0I52R5zaM38tTG7ud ZNP2mHwY8/BH1fL4tHtmoKuPPpTEHilKj9gEh5UCVLhmRRgUXPitFqlgkC7t2U+cFHnI 4PKAxfZE+WUP5G6H6iIt0OP9r+gRuu3c1UfnrokoARhsuuzunU52jINswX+OJEgeWqJA ipww== X-Forwarded-Encrypted: i=1; AJvYcCVQNWr6uzn0ochGMFDJTSNu21Kx0GIEEeW12l3hBMLXXTVKXYvkzb9rzF732wX5zkFz7dnX32kBt3G2XfKCve0=@freebsd.org X-Gm-Message-State: AOJu0YyBzs19bnuHNAnYJbxclb78fizKRonVdtWBzXvT/hkAWZjxCsao y1nsoVSGh3FEjKyuTNDFJrvcsE6STItYKQ1OV7mFXjo8bFLU6aLBDZORh0wk7+FzXp2hNgntTLK Rdke/xUt3GZsSCBZHSfsHFZTHKYuecIheftr7eQ== X-Gm-Gg: ASbGncs/c7PlE4EUFFk8bNuIYPnIFpMmSVbHOOLgOYLRwE/GMsyYtJdwG9NwhsQR27l GB6nKBm9PqWNKFEej+xKlyYnBrywnooXlVWNfNi7dV/daeNwW3y6b+dEbv/4/B/eVkaKfvypk6v lKVhJKTbdQFYZxyL6+JMNdEA== X-Google-Smtp-Source: AGHT+IHrpCBROM7cMKdIKrSdrZPX5ZdH/q9OfFGlI/k+XOf4UIbBwoNhlgMpI8gPBSUuYzpQ62YkfQZ5MgoASVgiqm4= X-Received: by 2002:a17:90a:d64f:b0:2fe:d766:ad95 with SMTP id 98e67ed59e1d1-3087bb47646mr19533676a91.9.1745252998586; Mon, 21 Apr 2025 09:29:58 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> <86bjsr5jv8.fsf@ltc.des.dev> <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> <20250421092301.724f623f@ernst.home> <7fdc20653ac8aa60dca6859ca81abbcd@bsdforge.com> In-Reply-To: <7fdc20653ac8aa60dca6859ca81abbcd@bsdforge.com> From: Warner Losh Date: Mon, 21 Apr 2025 10:29:47 -0600 X-Gm-Features: ATxdqUHjHjS-pJKJExvVb5ub0cjxK2VUN3P3PS9at_4qarwrlymOQuulQSdusUg Message-ID: Subject: Re: New kernel doesn?t recognize ufs gpt root filesystem To: Chris Cc: garyj@gmx.de, freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Zh9nh0Gnxz3hcD X-Spamd-Bar: ---- On Mon, Apr 21, 2025 at 10:03=E2=80=AFAM Chris wro= te: > > On 2025-04-21 00:23, Gary Jennejohn wrote: > > On Sun, 20 Apr 2025 12:19:45 -0700 > > Chris wrote: > > > >> On 2025-04-20 01:15, Dag-Erling Sm=C3=B8rgrav wrote: > >> > Chris writes: > >> >> Warner Losh writes: > >> >> > Maybe this is a custom kernel without the label code. > >> >> It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But > >> >> I'm using the same kernconf as before. Was label removed from gener= ic > >> >> in the last 11 mos.? > >> Thanks for your reply! > >> > > >> > Please share: > >> > > >> > - The output of the `what` command on your old (working) kernel > >> FreeBSD 15.0-CURRENT #1 main-n270118-94b09d388b81-dirty: Mon May 13 > >> 12:57:41 > >> PDT 2024 > >> > >> > - The output of the `what` command on your new (failing) kernel > >> FreeBSD 15.0-CURRENT #0 main-n276516-65d8491719bb: Sat Apr 19 17:41:06= PDT > >> 2025 > >> > >> > - The kernel configuration file you used to build the new kernel > >> https://bitpit.us/kern/LENOIP15ND-NEW > >> > >> here's the old kernconf: > >> https://bitpit.us/kern/LENOIP15ND-OLD > >> > >> and here's a convenient diff of them: > >> https://bitpit.us/kern/LENODIFF > >> > > > > Removing ctl might be a problem since it supports: > > /sys/conf/files:cam/ctl/ctl_nvme_all.c > > /sys/conf/files:cam/ctl/ctl_nvme_cmd_table.c > > and you have nvme in your kernel config files. > > > > But I'm not sure about that since I don't have nvme in my config file. > > > >> > - The contents of `/var/run/dmesg.boot` after booting the old kernel > >> https://bitpit.us/kern/dmesg.boot > >> > > > > A diff of the new and old /var/run/dmesg.boot files might be useful. > Indeed. But I'm not sure how I might obtain one. Since the new kernel > can't find a drive to write to. :) > I guess I could take a movie. But that'd be hell to transcribe. Any way > to redirect the console to a remote host without having much of a system > yet available? You might try the new kernel with set hw.nvme.use_nvd=3D1 at the boot loader prompt. Then you'll see you have a nvd device you could = mount root on and then you could add 'device da' back to the kernel config and rebuild. ... if you can't rebuild with the old kernel. Warner > Thanks for the hint, Gary. > > --Chris > > > > [SNIP] > > -- > sent from hardware written from and running on FreeBSD From nobody Mon Apr 21 16:55: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 4ZhBMF2fCKz5skQG for ; Mon, 21 Apr 2025 16:55:37 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZhBMD6tkqz40JQ for ; Mon, 21 Apr 2025 16:55:36 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53LGtMGN056480; Mon, 21 Apr 2025 09:55:28 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1745254535; x=1745255135; r=y; bh=gb3pu6KWvNH44sCP8B8mhkYUjWoyBsGg+T1RMPMebnE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=pgeYoKjw1CncFUfHSDI71Pe2ocfu4G3VueIZ1Q7FN/PO87Epr/sYDN79RPJyBV1Z6 pr9ERIP/YxeIBkf9yLUDBkOaL+HF6YXVcGucRzCdig3CU6UcSyIwsDvYc9bhUpAqks jeDq5+OFcCpWMDfS8BFyWIazqsywTSVymAXkyP7lMN9C5/OKx4dYjtG5JpqdRAacKz pFG0HPW6h8h4NnQOEuCiD0HNIvQheSdHO5p+kK5qdvTGtxancBhlsQ2dxdhpF9YO8D sUAIWLeONK6MrZIviBAB3WjRrNOfLyP1vb7+4SoutIeakTxQXS96T9dJyU8dakjl6K 9wz2aYGpEKnoA== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Mon, 21 Apr 2025 09:55:21 -0700 From: Chris To: Warner Losh Cc: garyj@gmx.de, freebsd-current Subject: Re: New kernel doesn?t recognize ufs gpt root filesystem In-Reply-To: References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> <86bjsr5jv8.fsf@ltc.des.dev> <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> <20250421092301.724f623f@ernst.home> User-Agent: UDNSMS/17.0 Message-ID: <9a2714907e1e2a49779aceb3e9e5e64a@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_e87953bde27ca7178a85fe372fde1124" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4ZhBMD6tkqz40JQ X-Spamd-Bar: ---- --=_e87953bde27ca7178a85fe372fde1124 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-04-21 06:42, Warner Losh wrote: > Put 'da' back in. I'm pretty sure it's not optional. Well, maybe it is > optional, but you'll need nda if you do that and the kernel config > doesn't have that. While you have nvd, the default is to prefer nda to > nvd, even when nda isn't in the kernel (so more like an either or > choice than a bidding choice: CAM device nodes don't have a bidding > process to them, and even if they did nvd vs nda crosses between CAM > and non-CAM and there's just no good way to cope). Sigh. This is clearly a case of lack of due diligence on my part (blindly recycling my kernconf). I want to apologize to everyone for inadvertently making you all do my work. :( Indeed. Why the heck would I *not* want da and friends?! Without it I can (at least) safely kiss any usb stick goodbye -- D'OH! :/ Thanks for the clue bat, Warner. :) Sorry for all the bother. --Chris > > Warner > > On Mon, Apr 21, 2025 at 1:23 AM Gary Jennejohn wrote: >> >> On Sun, 20 Apr 2025 12:19:45 -0700 >> Chris wrote: >> >> > On 2025-04-20 01:15, Dag-Erling Smørgrav wrote: >> > > Chris writes: >> > >> Warner Losh writes: >> > >> > Maybe this is a custom kernel without the label code. >> > >> It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But >> > >> I'm using the same kernconf as before. Was label removed from generic >> > >> in the last 11 mos.? >> > Thanks for your reply! >> > > >> > > Please share: >> > > >> > > - The output of the `what` command on your old (working) kernel >> > FreeBSD 15.0-CURRENT #1 main-n270118-94b09d388b81-dirty: Mon May 13 12:57:41 >> > PDT 2024 >> > >> > > - The output of the `what` command on your new (failing) kernel >> > FreeBSD 15.0-CURRENT #0 main-n276516-65d8491719bb: Sat Apr 19 17:41:06 PDT >> > 2025 >> > >> > > - The kernel configuration file you used to build the new kernel >> > https://bitpit.us/kern/LENOIP15ND-NEW >> > >> > here's the old kernconf: >> > https://bitpit.us/kern/LENOIP15ND-OLD >> > >> > and here's a convenient diff of them: >> > https://bitpit.us/kern/LENODIFF >> > >> >> Removing ctl might be a problem since it supports: >> /sys/conf/files:cam/ctl/ctl_nvme_all.c >> /sys/conf/files:cam/ctl/ctl_nvme_cmd_table.c >> and you have nvme in your kernel config files. >> >> But I'm not sure about that since I don't have nvme in my config file. >> >> > > - The contents of `/var/run/dmesg.boot` after booting the old kernel >> > https://bitpit.us/kern/dmesg.boot >> > >> >> A diff of the new and old /var/run/dmesg.boot files might be useful. >> >> [SNIP] >> >> -- >> Gary Jennejohn >> -- sent from hardware written from and running on FreeBSD --=_e87953bde27ca7178a85fe372fde1124 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_e87953bde27ca7178a85fe372fde1124-- From nobody Mon Apr 21 17:01: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 4ZhBVN40hMz5sl0c for ; Mon, 21 Apr 2025 17:01:48 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZhBVN0ybTz44NX for ; Mon, 21 Apr 2025 17:01:48 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53LH1eco081379; Mon, 21 Apr 2025 10:01:46 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1745254906; x=1745255506; r=y; bh=Zu2hhFXklCscKnV8QY+1ap98Jg7TwFCJpBxTEEXRGcY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=RJWNhtsM/Ve2VAwsSXzS4Q5wIHdYbdQLfZs8wJ+lswm4dBwHH3vjALpTYvrsE3rtY nxqPZSyChZdKPMe2QGNwhkbQjV0AyzFtFMEK/oz0gnFmbFE2eVUHQZ9nIzi54jOteT n/dntzUSWQR1l//3LMDhX6INGZZf+aWzTzhdzb2dNrU+IlhiOlbJy7Fs7mJ/EIjuxy +tPTU2H2HZ4CS086WlaP22SoIJ81m2y9Bls93b7YYNkiPjE5eJBwgO6biqZ9ngjn72 s5eqXKR9KcksmP6ZK5CEXmQ/tF64TeEPJ9Xui9+kH+a6vu580fqyAlmhzFfkLlZSbx SIvxwcGzy7KqA== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Mon, 21 Apr 2025 10:01:39 -0700 From: Chris To: Warner Losh Cc: garyj@gmx.de, freebsd-current Subject: Re: New kernel doesn?t recognize ufs gpt root filesystem In-Reply-To: References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> <86bjsr5jv8.fsf@ltc.des.dev> <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> <20250421092301.724f623f@ernst.home> <7fdc20653ac8aa60dca6859ca81abbcd@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_c96e4a46777d9176da5af572f3d18110" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4ZhBVN0ybTz44NX X-Spamd-Bar: ---- --=_c96e4a46777d9176da5af572f3d18110 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-04-21 09:29, Warner Losh wrote: > On Mon, Apr 21, 2025 at 10:03 AM Chris wrote: >> >> On 2025-04-21 00:23, Gary Jennejohn wrote: >> > On Sun, 20 Apr 2025 12:19:45 -0700 >> > Chris wrote: >> > >> >> On 2025-04-20 01:15, Dag-Erling Smørgrav wrote: >> >> > Chris writes: >> >> >> Warner Losh writes: >> >> >> > Maybe this is a custom kernel without the label code. >> >> >> It's an upgrade. It's 15 from ~11 mos ago. Yes a custom kernel. But >> >> >> I'm using the same kernconf as before. Was label removed from generic >> >> >> in the last 11 mos.? >> >> Thanks for your reply! >> >> > >> >> > Please share: >> >> > >> >> > - The output of the `what` command on your old (working) kernel >> >> FreeBSD 15.0-CURRENT #1 main-n270118-94b09d388b81-dirty: Mon May 13 >> >> 12:57:41 >> >> PDT 2024 >> >> >> >> > - The output of the `what` command on your new (failing) kernel >> >> FreeBSD 15.0-CURRENT #0 main-n276516-65d8491719bb: Sat Apr 19 17:41:06 PDT >> >> 2025 >> >> >> >> > - The kernel configuration file you used to build the new kernel >> >> https://bitpit.us/kern/LENOIP15ND-NEW >> >> >> >> here's the old kernconf: >> >> https://bitpit.us/kern/LENOIP15ND-OLD >> >> >> >> and here's a convenient diff of them: >> >> https://bitpit.us/kern/LENODIFF >> >> >> > >> > Removing ctl might be a problem since it supports: >> > /sys/conf/files:cam/ctl/ctl_nvme_all.c >> > /sys/conf/files:cam/ctl/ctl_nvme_cmd_table.c >> > and you have nvme in your kernel config files. >> > >> > But I'm not sure about that since I don't have nvme in my config file. >> > >> >> > - The contents of `/var/run/dmesg.boot` after booting the old kernel >> >> https://bitpit.us/kern/dmesg.boot >> >> >> > >> > A diff of the new and old /var/run/dmesg.boot files might be useful. >> Indeed. But I'm not sure how I might obtain one. Since the new kernel >> can't find a drive to write to. :) >> I guess I could take a movie. But that'd be hell to transcribe. Any way >> to redirect the console to a remote host without having much of a system >> yet available? > > You might try the new kernel with > set hw.nvme.use_nvd=1 I thought of that after reading your last reply. > at the boot loader prompt. Then you'll see you have a nvd device you could > mount > root on and then you could add 'device da' back to the kernel config > and rebuild. > ... if you can't rebuild with the old kernel. Can I safely move my new kernel to say, kernel.new while running my current kernel as kernel and rebuild the new kernel with the kernconf corrections? Will that achieve the desired installkernel results? Thanks for all your time and consideration, Warner and sorry for subjecting you to all this rookie nonsense. I already know better. :/ ---Chris > > Warner > >> Thanks for the hint, Gary. >> >> --Chris >> > >> > [SNIP] >> >> -- >> sent from hardware written from and running on FreeBSD -- sent from hardware written from and running on FreeBSD --=_c96e4a46777d9176da5af572f3d18110 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_c96e4a46777d9176da5af572f3d18110-- From nobody Mon Apr 21 17:47:55 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZhCWf3Vgqz5snhb for ; Mon, 21 Apr 2025 17:47:58 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZhCWd5BNzz3XcD; Mon, 21 Apr 2025 17:47:57 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745257677; 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=hyTRuXzKBuKKvL+I7AQpcmGYtpDHyM+OBAR3ET1VPAo=; b=sttqBTcnUfj/gldBfYLRMNwWYrj+omKJY35SfeydZVX7++qR8XXejm8/8UG8P/V8F+Ry8b oerTG3x8h1zaNFo2A8ohv3Sxvc6nNmL1OfwPwCIcsLqOvH9m487KdLT0zI+z3uKv7sNWjt suxK9bKH0NyJFYvgTTqXFzjcsuTQJaVT5OO5ufhErd7YjD099aa65mArl+7RSEKu66GtUX 3FZ4wm6t8xddrz45SL95q+5K+QLAJc/NF13C11bVcENazR+pOLutBC9sytry77hAQEkQ0n mhtCqFlfPrd48lZsYNl9JP+cgaaO8l2Jz7LlMFP2AuHnCCaLQBxL1JDxZLrZrw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745257677; a=rsa-sha256; cv=none; b=DTpb8Rw4mmOa80DcwdDt7DBE2k4B9/RgnlTgb7+s2rg+9WeB849pyx7jcUDijxaJBNEZHq k9VdIwVoHmjNSBBsgwDx1ra200tlHKSzkq/oBcRUKGf+0LEBJpr3E0wYU93DFx65adm7bN t0PxnWgLg1L+O2w1wD+IvJBuNei8csaOKzUyPHtuG9boMgVVK8JCM+pyxYhz5yZvi7p/VI qLtzfE6FFk2+ak9fvfAdQYQGD+iKEX8O/zZTqsQ4PzYYWuiMxWqz5sOUUjCFGxBlBE6Ytr +5au67cSIbbMh86ZZBF9CFX8t3S6F8ZKRCh23dT0LCBPJAgA4Pu+gYcOn6ZcWA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745257677; 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=hyTRuXzKBuKKvL+I7AQpcmGYtpDHyM+OBAR3ET1VPAo=; b=cp3tfbEfIG/26dfhLPQDWz9eAy8E/TyS3i9JrQ+HcTqrd6LAoHszObjVREsREAEtNIU74J 6yHUy8WPmDztQzV3gEhkg6WC76oEkSuPGGTH+GBygdewf9oGjYXfN5PygLgS0VO5I/sSVP LLmLLuZKgczxSyMhrcQZM3Fd9D2JstNVFf919pLIq2c7gO3ETGz5eBO4wyEqYYIvjMoz8H AGy09/W+xQozZDbMw4OawTjEK7s4HRxy11swzDyc2Ix2+2el8uYpIAkOnBA2equpTTj6wE eT04UaMl2vlU2ho7/6OYh9Ofi9p1h+8f/1Ay6/t+M+js9J5sJ1yYxMd0t/zoKQ== Received: from ltc.des.dev (88-177-82-251.subs.proxad.net [88.177.82.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZhCWd3j5JzQ9C; Mon, 21 Apr 2025 17:47:57 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 066A3FAC02; Mon, 21 Apr 2025 19:47:56 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Chris Cc: Warner Losh , garyj@gmx.de, freebsd-current Subject: Re: New kernel doesn?t recognize ufs gpt root filesystem In-Reply-To: (Chris's message of "Mon, 21 Apr 2025 10:01:39 -0700") References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> <86bjsr5jv8.fsf@ltc.des.dev> <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> <20250421092301.724f623f@ernst.home> <7fdc20653ac8aa60dca6859ca81abbcd@bsdforge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Mon, 21 Apr 2025 19:47:55 +0200 Message-ID: <8634e15ruc.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Chris writes: > Can I safely move my new kernel to say, kernel.new while running my curre= nt > kernel as kernel and rebuild the new kernel with the kernconf corrections? If you're booted into kernel.old you can just build a new kernel and run `make reinstallkernel` to replace the new (non-working) kernel without touching kernel.old. Same if you're booted into the new kernel with some sort of workaround and want to preserve the old kernel. It is 100% safe to replace or rename the kernel and modules, even the one you're currently running. Just be aware that you may have trouble loading modules afterward. If for instance you boot into kernel.old and then rename /boot/kernel.old to /boot/kernel.works as I suggested earlier, you won't be able to load kernel modules until you update `kern.bootfile` to point to the new location of the running kernel (`make installkernel` does this when it renames the running kernel to kernel.old). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Mon Apr 21 18:46:42 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 4ZhDqb0ndqz5ss0K for ; Mon, 21 Apr 2025 18:46:51 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZhDqZ3ymXz4525; Mon, 21 Apr 2025 18:46:50 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53LIkgwK032310; Mon, 21 Apr 2025 11:46:48 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1745261208; x=1745261808; r=y; bh=SMDCcwJJX2JDRPN9aLIEOzdfEp5k7wEFwFNS1OZhKRg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=HZtzs8djoAMWJFB0WLbKeECY/0mBI0hGHGUisZuQsNN5Mpev52+GH4uo38ZeGw9+O AZg3BoXBcpU8dyE0SFRfZeTjWB3T7pd5yYnujGTSL2WyrCYYCk5ixz3EENqMCMgKz+ N0L3+/0fXYAMllp9NvT+5w+UtMGusxdNOR6XTu45s9ob13DPWY64NYyEeHET/JhhTg 4RLEvfckHI/zxTI1HCuZnBWlU1eIvyfbYQ6XRRsI5pPYEToEJLmwLBgC/uMowXtXfS YNXMFAdPLouJ3jyS/bje/+5u0mCVh7Rxvt5OAsL/5ra/jkHUB9a85RgPzslYQXM5Lq 7JpzKxQwjgjcQ== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Mon, 21 Apr 2025 11:46:42 -0700 From: Chris To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: Warner Losh , garyj@gmx.de, freebsd-current Subject: Re: New kernel doesn?t recognize ufs gpt root filesystem In-Reply-To: <8634e15ruc.fsf@ltc.des.dev> References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> <86bjsr5jv8.fsf@ltc.des.dev> <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> <20250421092301.724f623f@ernst.home> <7fdc20653ac8aa60dca6859ca81abbcd@bsdforge.com> <8634e15ruc.fsf@ltc.des.dev> User-Agent: UDNSMS/17.0 Message-ID: <1e9587924c07c24067120320fca5e118@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_1874f5404c99165679a13d04d3183970" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4ZhDqZ3ymXz4525 X-Spamd-Bar: ---- --=_1874f5404c99165679a13d04d3183970 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-04-21 10:47, Dag-Erling Smørgrav wrote: > Chris writes: >> Can I safely move my new kernel to say, kernel.new while running my current >> kernel as kernel and rebuild the new kernel with the kernconf corrections? > > If you're booted into kernel.old you can just build a new kernel and run > `make reinstallkernel` to replace the new (non-working) kernel without > touching kernel.old. Sorry. But this the first failed kernel in some 40+ years. So I'm now second guessing every move I make... So if I break to the boot prompt and choose boot kernel.old followed by cd /usr/src, make buildkernel KERNCONF=, make reinstallkernel KERNCONF= boot -s installworld dance. I'm good to go? Thanks! I really appreciate all the hand holding here. Sorry for all the trouble. --Chris > > Same if you're booted into the new kernel with some sort of workaround > and want to preserve the old kernel. > > It is 100% safe to replace or rename the kernel and modules, even the > one you're currently running. Just be aware that you may have trouble > loading modules afterward. If for instance you boot into kernel.old and > then rename /boot/kernel.old to /boot/kernel.works as I suggested > earlier, you won't be able to load kernel modules until you update > `kern.bootfile` to point to the new location of the running kernel > (`make installkernel` does this when it renames the running kernel to > kernel.old). > > DES -- sent from hardware written from and running on FreeBSD --=_1874f5404c99165679a13d04d3183970 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_1874f5404c99165679a13d04d3183970-- From nobody Mon Apr 21 19:32:59 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZhFsD4cbqz5sw2f for ; Mon, 21 Apr 2025 19:33:20 +0000 (UTC) (envelope-from info@spmzt.net) Received: from mail.spmzt.net (mail.spmzt.net [185.44.82.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZhFsC2r18z3Kk1 for ; Mon, 21 Apr 2025 19:33:19 +0000 (UTC) (envelope-from info@spmzt.net) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=spmzt.net header.s=dkim header.b=fjSKjPSQ; dmarc=pass (policy=quarantine) header.from=spmzt.net; spf=pass (mx1.freebsd.org: domain of info@spmzt.net designates 185.44.82.22 as permitted sender) smtp.mailfrom=info@spmzt.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spmzt.net; s=dkim; t=1745263989; 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=dWr4yMEAtFkOXCrvsyj7R4t1Re7FDRTbXu3nK/+FcHQ=; b=fjSKjPSQNqeZI9PZBDsu4X1Y7XloT7/m6YJ6heHuqq/2s3ezvW/Q0XAhaHJXiZi3A+SXxU d04XJobeEN0XfDvzmiSttSA5bMspTcLqnQsDPEQFfp+rfPAbI7vwJW5fDKiDjMwYwvNMBP QhyVE2wYPzDzajbX94M+V5FRH1reRL4= Received: by mail.spmzt.net (OpenSMTPD) with ESMTPSA id ecc3fa29 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Tue, 22 Apr 2025 00:03:08 +0430 (+0430) Message-ID: <71c57a10-b21b-4a16-bce4-e933c6e0f95b@spmzt.net> Date: Mon, 21 Apr 2025 23:02:59 +0330 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: graphics/drm-61-kmod build failure for main-n276560-83dcc133c876 To: current@freebsd.org References: Content-Language: en-US, fa-IR From: Seyed Pouria Mousavizadeh Tehrani Organization: SPMZT - AS214145 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------bkvRc0WO7zNUK0x5xP8BZWRi" X-Spamd-Result: default: False [-1.71 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.97)[-0.975]; NEURAL_SPAM_MEDIUM(0.97)[0.966]; DMARC_POLICY_ALLOW(-0.50)[spmzt.net,quarantine]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed]; R_SPF_ALLOW(-0.20)[+mx]; MIME_HTML_ONLY(0.20)[]; HAS_ATTACHMENT(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~,3:~]; HAS_ORG_HEADER(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_PERMFAIL(0.00)[spmzt.net:s=dkim]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[spmzt.net:~]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:34927, ipnet:185.44.82.0/24, country:CH]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZhFsC2r18z3Kk1 X-Spamd-Bar: - This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------bkvRc0WO7zNUK0x5xP8BZWRi Content-Type: multipart/mixed; boundary="------------5wE0kP08crVZzpWh6IZF28bn"; protected-headers="v1" From: Seyed Pouria Mousavizadeh Tehrani To: current@freebsd.org Message-ID: <71c57a10-b21b-4a16-bce4-e933c6e0f95b@spmzt.net> Subject: Re: graphics/drm-61-kmod build failure for main-n276560-83dcc133c876 References: In-Reply-To: --------------5wE0kP08crVZzpWh6IZF28bn Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 4/19/25 17:32, Mark Johnston wrote:= 
Something like the following=
 diff is needed.  It needs to be built
against the latest main, where __FreeBSD_version is bumped.

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i=
915/gem/i915_gem_mman.c
index 2a9946c7d0..f61eeefe7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -34,6 +34,7 @@
 #include <vm/vm_object.h>
 #include <vm/vm_pager.h>
 #include <vm/vm_param.h>
+#include <vm/vm_radix.h>
 #endif
=20
 #ifdef __linux__ /* Mute unused function warning. */
@@ -168,9 +169,16 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *da=
ta,
 	if ((rv =3D=3D KERN_SUCCESS) && (args->flags & I915_MMAP=
_WC)) {
 		VM_OBJECT_WLOCK(vmobj);
 		if (vm_object_set_memattr(vmobj, VM_MEMATTR_WRITE_COMBINING) !=3D KERN=
_SUCCESS) {
-			for (vm_page_t page =3D vm_page_find_least(vmobj, 0); page !=3D NULL;=
 page =3D vm_page_next(page)) {
+#if __FreeBSD_version >=3D 1500038
+			struct pctrie_iter pages;
+			vm_page_t page;
+
+			vm_page_iter_init(&pages, vmobj);
+			VM_RADIX_FORALL(page, &pages)
+#else
+			for (vm_page_t page =3D vm_page_find_least(vmobj, 0); page !=3D NULL;=
 page =3D vm_page_next(page))
+#endif
 				pmap_page_set_memattr(page, VM_MEMATTR_WRITE_COMBINING);
-			}
 		}
 		VM_OBJECT_WUNLOCK(vmobj);
 	}


I had the same problem, applied this patch and it works. (i915kms and nvidia-drm)

--=20
Seyed Pouria Mousavizadeh Tehrani
--------------5wE0kP08crVZzpWh6IZF28bn-- --------------bkvRc0WO7zNUK0x5xP8BZWRi Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSqt7cppfvJ816gj0lUwVnUeMwagAUCaAadawAKCRBUwVnUeMwa gBl4AP9t69nZsGTrPhL/g6DK9dcIwi7QRWVVpVeDXqJvGEnkGQEA8RLGg58swOZj yvn7xN43UnIjleSP/+OiBqqxy5s+Qws= =Y+Lz -----END PGP SIGNATURE----- --------------bkvRc0WO7zNUK0x5xP8BZWRi-- From nobody Mon Apr 21 22:37:55 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZhKyW3FNWz5t82n for ; Mon, 21 Apr 2025 22:38:11 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 4ZhKyV53x6z45gQ; Mon, 21 Apr 2025 22:38:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=XJCIt4BW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5efe8d9eb1eso4621893a12.0; Mon, 21 Apr 2025 15:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745275088; x=1745879888; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=uuLRcp9/XULKPozEDGN7ERT0e16QkdY2Dq7CGPmYhdI=; b=XJCIt4BWLcNcxdqvbrHlYSmeNs4yBfimTx6nEVCkEz1Xtah8iMwzvVcbS6BZrlgZqB 70jH5lTM1jPeX5t3rc1czikNgbR5ZR2oXbJi04xH3CbWyJq0apwED25sA1e3tl+V+ImP JOm3N7InYi/GFcV73YaE0oXqmOpkTjIl0tryro9jSqQdnGYEH7/eTLyb2xAAqroq8syD d8OEaEjiMjZRyv2wgkktR4zXP5byGoyT/3tUC7I53olnaMTZiuEYyyDBsVtinMAxeGuf NDmvlBx6CnDMloOpQ0tSlYpNFLkO3AQR4DJUcgpPZo9g6vhSH1OFpu699TQ7mf5fwUzC 8AiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745275088; x=1745879888; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uuLRcp9/XULKPozEDGN7ERT0e16QkdY2Dq7CGPmYhdI=; b=iyFjTb/7cwTQqAqeTlrIVz/8VJCd0T92GyzfAzI+N4DAYCxTmndKMjaLWXfa1Ihrlu LsiIUNwtLfOYmqXUdFRQQkv543yCotqJiB3sqVbkP4hY70wP55Y4+t/Bj+ajdPlcDzIv 6v9avj9HbMv2lJRb36VGhKyHCyBYVArtW6P3Jg9PkLikC9xKNvqVqp4gpT+jPkDKolCh MGX4R8yyTnQEDc/Ok77bshBeSxmCJwn2XoEX8F4xBGnnyjNScMC0SJ09Gp2EUf2MjHsg G0Xf/UGwBa/dtx1YtLeHN5EyMqR5GeBmXOrpUvHdIebCQuah1q8iKE88q4jr7bPS2k/7 tM9w== X-Forwarded-Encrypted: i=1; AJvYcCWAX2NA2Jk85ODoCWcpwHjdOo9aYvHHUnobO+Xrn+lLv+KrYk0ue/D3snjrd9AU9/s6mvM=@freebsd.org X-Gm-Message-State: AOJu0YxxF6FZ3VGFqNaUt4abjcxbalnsk1vk7gnjS8OxPlMMZK7hnsyW FdJG6YBNw+GHBgryrglgORcwQ4wYCsOv1Hk4DPV+QUNqqd6miZCS2vYDHqDTNGnHiibQ2y5v3zh 8xQyumQ6myUKdgTwWRl91aytKCUPRJdQ= X-Gm-Gg: ASbGncvO9VY9sF5qUX6q7X5WxCvtbvgKrL1SPYE9PlSsz6cPP1HtMbJ6UGFbv24QoDm UY858Nk+t0hYukjYRpYBZfSEUUZ9d4dmO3KJ93wSOKHthQKhpeW4UJTzDb+5Eyp2+DtC95EZpxq MUx975ejGkpA9CbAl+PWZTBG3RI5nTksYcvxdXqBxkJaSAfY1cvtIy+Q== X-Google-Smtp-Source: AGHT+IEebx1/SKXoOW61EHwuTUYOGG9fUuebn8NwzCpLn2As1WIi7S9AXUZt8+DGczEBEKwJnSPAU1tQSaEvQ45vzJQ= X-Received: by 2002:a05:6402:84c:b0:5db:68bd:ab78 with SMTP id 4fb4d7f45d1cf-5f627d4bbd6mr12114228a12.10.1745275087389; Mon, 21 Apr 2025 15:38:07 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 From: Rick Macklem Date: Mon, 21 Apr 2025 15:37:55 -0700 X-Gm-Features: ATxdqUG1uAQzvYm9bpL0UreEQnls78Y-oFMgsrDdaRIXWripl37nUbQsXtv36OA Message-ID: Subject: LK_RETRY set in cn_lkflags for VOP_LOOKUP? To: FreeBSD CURRENT , Konstantin Belousov Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [0.73 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_LONG(1.00)[0.999]; NEURAL_HAM_SHORT(-0.95)[-0.946]; NEURAL_SPAM_MEDIUM(0.67)[0.673]; 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]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; TAGGED_FROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZhKyV53x6z45gQ X-Spamd-Bar: / Hi, I just spotted something in the NFS server that seems like it is a bug, but I thought I'd check. (Note that I have never seen this cause a problem, but I think it might if a server file system is being forced dismounted while the NFS server is accessing it.) What I spotted was a few places where: cnp->cn_lkflags = LK_SHARED | LK_RETRY; ... error = VOP_LOOKUP(..); I don't think LK_RETRY should be set here. For example vget_finish() uses the flags argument for a "error = vn_lock(..flags);", which would retry instead of returning an error when the vnode is VI_DOOMED. So, is this a bug that needs to be fixed? Thanks, rick From nobody Tue Apr 22 00:55:43 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZhP1N2TZSz5tHs5 for ; Tue, 22 Apr 2025 00:55:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZhP1M0Svxz3WX7; Tue, 22 Apr 2025 00:55:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 53M0thpi033917; Tue, 22 Apr 2025 03:55:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 53M0thpi033917 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 53M0thsw033916; Tue, 22 Apr 2025 03:55:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Apr 2025 03:55:43 +0300 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD CURRENT , Konstantin Belousov Subject: Re: LK_RETRY set in cn_lkflags for VOP_LOOKUP? Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Result: default: False [2.13 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_HAM_SHORT(-0.87)[-0.874]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4ZhP1M0Svxz3WX7 X-Spamd-Bar: ++ On Mon, Apr 21, 2025 at 03:37:55PM -0700, Rick Macklem wrote: > Hi, > > I just spotted something in the NFS server that seems like > it is a bug, but I thought I'd check. > (Note that I have never seen this cause a problem, but I > think it might if a server file system is being forced > dismounted while the NFS server is accessing it.) > > What I spotted was a few places where: > cnp->cn_lkflags = LK_SHARED | LK_RETRY; > ... > error = VOP_LOOKUP(..); > I don't think LK_RETRY should be set here. > For example vget_finish() uses the flags argument > for a "error = vn_lock(..flags);", which would retry > instead of returning an error when the vnode is VI_DOOMED. > > So, is this a bug that needs to be fixed? I think LK_RETRY is not appropriate there, and ought to be removed. But it should not be critical by itself. The doomed vnode might cause some further VOP calls to fail, and NFS server must be prepared to that, correctly handling the error. I looked at the output of grep 'cn_lkflags.*LK_RETRY', and it seems that the error handling is proper, although the readdirplus code is somewhat too much to make the claim. As a curiousity, there is one more place with this pattern in zfs. From nobody Tue Apr 22 03:55: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 4ZhT1M0cfGz5tW1W for ; Tue, 22 Apr 2025 03:56:07 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZhT1L2qFpz417v; Tue, 22 Apr 2025 03:56:06 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=ultimatedns.net header.s=mx99 header.b=ZscUSbIz; dmarc=pass (policy=none) header.from=bsdforge.com; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 53M3tpfP088760; Mon, 21 Apr 2025 20:55:57 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1745294164; x=1745294764; r=y; bh=rDWTqBqGk+cJOURmWJA75A3/DJFN2n8OVn0D5D37hVM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ZscUSbIzRr9isU+RXGJvp0738RUpFxl9rrEbsBcY4jgkGP0dN6MqRPm+ZaqX6m7Cg OrKh/cyWuHDLSsBx2So/YyFjXhF0d8GXwQuFNZ2eB/8TJfgDsNCqknH1R88Qz0ydUs +t/GlZLvm2i4rV10ZD4u3n+xCsA0C68d6H+yrZSUvNh+7qI1imIz+9JeXIHEXzyuzf 2jS7UH49wNxX92yF9Na4crioYtXcfb171C5IlaZcc5s8U65maj5+oW0h2/6MxPS7+r 58Sh20CWRHwhtCevH0IwpLVqT34Ciuy4zqMcaUbmOtrpkRwNPmiuW8LORgDwQIwZe7 z1WrCuYHxh+ag== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Mon, 21 Apr 2025 20:55:50 -0700 From: Chris To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: Warner Losh , garyj@gmx.de, freebsd-current Subject: Re: New kernel doesn?t recognize ufs gpt root filesystem In-Reply-To: <1e9587924c07c24067120320fca5e118@bsdforge.com> References: <811fddf82af288d409fc5df1c5b5d958@bsdforge.com> <809aba26a8884f36ae32a6f253345b3b@bsdforge.com> <86bjsr5jv8.fsf@ltc.des.dev> <93cecfcebd42c222ec8f283b891b19dc@bsdforge.com> <20250421092301.724f623f@ernst.home> <7fdc20653ac8aa60dca6859ca81abbcd@bsdforge.com> <8634e15ruc.fsf@ltc.des.dev> <1e9587924c07c24067120320fca5e118@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_fb8224113a580a2b419d64d03b54935a" X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.50 / 15.00]; R_DKIM_REJECT(1.00)[ultimatedns.net:s=mx99]; DMARC_POLICY_ALLOW(-0.50)[bsdforge.com,none]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip4:24.113.41.81/29:c]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; ARC_NA(0.00)[]; local_wl_ip(0.00)[24.113.41.81]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[ultimatedns.net:-]; HAS_ATTACHMENT(0.00)[]; FREEMAIL_CC(0.00)[bsdimp.com,gmx.de,freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-Rspamd-Queue-Id: 4ZhT1L2qFpz417v X-Spamd-Bar: / --=_fb8224113a580a2b419d64d03b54935a Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-04-21 11:46, Chris wrote: > On 2025-04-21 10:47, Dag-Erling Smørgrav wrote: >> Chris writes: >>> Can I safely move my new kernel to say, kernel.new while running my >>> current >>> kernel as kernel and rebuild the new kernel with the kernconf corrections? >> >> If you're booted into kernel.old you can just build a new kernel and run >> `make reinstallkernel` to replace the new (non-working) kernel without >> touching kernel.old. > Sorry. But this the first failed kernel in some 40+ years. So I'm now second > guessing every move I make... > > So if I break to the boot prompt and choose boot kernel.old > followed by cd /usr/src, make buildkernel KERNCONF=, > make reinstallkernel KERNCONF= > boot -s > installworld dance. I'm good to go? Just an update to indicate I answered myself and performed a $ mv /boot/kernel.old /boot/kernel (old kernel that worked) $ cp -rp /boot/kernel /boot/kernel-save (as per your advice) left broken /boot/krernel.new as is. rebooted with revised KERNCONF now in place $ cd /usr/src $ make -j4 -DALWAYS_CHECK_MAKE buildkernel KERNCONF= $ make -j4 -DALWAYS_CHECK_MAKE installkernel KERNCONF= rebooted single-user perform the installworld dance reboot build/install iwlwifi-firmware reboot now having an internet connection again build/install gpu/drm bits and reboot to a fully working system. Thanks a million to you,Warner and Gary for all the time you gave me for this. Sorry for being a bit of a PITA. :( --Chris >> >> Same if you're booted into the new kernel with some sort of workaround >> and want to preserve the old kernel. >> >> It is 100% safe to replace or rename the kernel and modules, even the >> one you're currently running. Just be aware that you may have trouble >> loading modules afterward. If for instance you boot into kernel.old and >> then rename /boot/kernel.old to /boot/kernel.works as I suggested >> earlier, you won't be able to load kernel modules until you update >> `kern.bootfile` to point to the new location of the running kernel >> (`make installkernel` does this when it renames the running kernel to >> kernel.old). >> >> DES -- sent from hardware written from and running on FreeBSD --=_fb8224113a580a2b419d64d03b54935a Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_fb8224113a580a2b419d64d03b54935a-- From nobody Tue Apr 22 11:10:28 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 4Zhffq6mzGz5sT8P; Tue, 22 Apr 2025 11:10:43 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 4Zhffp51nFz40l5; Tue, 22 Apr 2025 11:10:42 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Hnf1iDVi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5f5bef591d6so8588136a12.1; Tue, 22 Apr 2025 04:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745320240; x=1745925040; 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=+mAY1hvhitkVMtz/PWLzYzrmPN+kmwG+uiYRRRkC4CE=; b=Hnf1iDVig+ZRampyQD3c36ehRzotBxf0VV6HaV/Iazks/lYZ4cZ+971EITRvPvidGm hgWyIezyOcCHGfgZZAUYqtUBfsDdfCtoeOdIjFKsbHVMMix9eejz+B0UKFzPoposEzXF eGFdBgxGfLvt+/tUsMA0d14MYSMxgm5bF8ETZOcmyw43xKi7+Rg4IyPjpKw73OTz066h 2favAny8TwnUMgijwFl0b7hwC9BgPhcOzdjhbGXdI/BLG2R1rXUIPvLfw6FxlRmL1nxY NCjoeLXc8x2z8H7K/umpgeZPcZQ8LJ88P6k3Y3WEGv3GV6JXNePoZdLxdqbY/GExVjm0 56Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745320240; x=1745925040; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+mAY1hvhitkVMtz/PWLzYzrmPN+kmwG+uiYRRRkC4CE=; b=jBAW8zomDql05wRqb+EXkkV02p7tQekAfEkSKTh1BIvI//eFRAxOJnwqyRrHgXcHii KveqInFWd0UK5XwfNOrlqXFhEBiAvSrNRPhm8llQuf4STgXo7ricTdlFCtBxtzrltPym EXCDHn7LWoEyM5OS82fAPUqSA9EGE3NuAWkHSoec65G1wrfXBgIzNKZBQFUFc4uQm48W 9FCzf9aOSZ0+W5+zQvNfoZBBv/Faunz7QvFegzHANTimE/uDIBH0xtNe5YsaMnouo2Ag Qizrx9cK6osHmogAIUlhhxR5/XV0PKxjePaXxAb2WJYDm5b9HnO6Z5IoD4Jbqny6DoSh 6F+w== X-Forwarded-Encrypted: i=1; AJvYcCVwP1g29UzfG3yag2xO+wbuRm9IWNMeJbI7wAYsApaW6WlmniDeqdgnKlDZIYa1wTaB/7Nj3mcALI2SUMFgkec=@freebsd.org X-Gm-Message-State: AOJu0Yy4ZA2kfkTJYxtfDlp5+Dt9cJFzR8O7oVodGS7ttxu98oF71pkI Zgd1Pgj9357y6njmDXkw6dPbUOIfrZkquhv4GgO7b7bOLaZn1OkgVZ3Q+DE0XJuVFY2+QQ+TrFF EZAsE6EzKHqbS3v2MdzY3Dntp4Q== X-Gm-Gg: ASbGncu0OdCNXizwSTMy2cBrBWF4mqWyJayjuQv7PUvsJE9lNbjZ9RRnPgh2DDOjdlo vx2yOchiAg9MRG9dUZqWcR6BfeW4Hv6a/DcG4BD6Jff6h+U8EzBlK/jPpX8TDEUDX6iqql8naJn xub5RDPeZ38Bm3omWXm/4uOUoWIGL2XNopy+WA1V5dIdhmpUiJ0xV8kSbF+E/nKqs= X-Google-Smtp-Source: AGHT+IF/Egz7MbijuH67Se4NH3un9a2/F4ApZDvjv7HC/CcR2Wg9xiWz4GzOEZ/3APHbRGZrB2XtWRzbN6kkx1Ob61w= X-Received: by 2002:a05:6402:5189:b0:5f6:c4ed:e270 with SMTP id 4fb4d7f45d1cf-5f6c4ede337mr792342a12.3.1745320240080; Tue, 22 Apr 2025 04:10:40 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Tue, 22 Apr 2025 04:10:28 -0700 X-Gm-Features: ATxdqUFS351mcCgE2BmR0BtNiSlwqUL3s-6837G-Ry77WEq2kUovYfkdmREZzF0 Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Cedric Blancher Cc: freebsd-arch@freebsd.org, FreeBSD CURRENT , Lionel Cons Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.11 / 15.00]; NEURAL_HAM_SHORT(-0.92)[-0.917]; NEURAL_HAM_MEDIUM(-0.86)[-0.859]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_LONG(-0.33)[-0.333]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4Zhffp51nFz40l5 X-Spamd-Bar: --- On Tue, Apr 22, 2025 at 3:34=E2=80=AFAM Cedric Blancher wrote: > > On Sun, 9 Mar 2025 at 00:02, Rick Macklem wrote: > > > > First off, I cross posted because I don't think many read freebsd-arch@= . > > There seems to be a nice market for Solaris style extended attributes. > > Since ZFS is already wired for them, adding the basics is pretty > > straightforward. I am not suggesting that they should replace the > > current FreeBSD extended attributes. > > > > For those not familiar with them (I am not very familiar myself;-), > > a Solaris style extended attribute is in a directory that hangs off > > the file object and the entries in the directory (the attributes) can > > be manipulated with open/read/write/lseek just like a regular file. > > (They can be as large as a regular file, but there is no atomicity > > guarantees.) > > > > At this point I have a couple of rough patches: > > https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part > > https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 part > > Any timeframe when > https://people.freebsd.org/~rmacklem/nfs-xattr.patch will land in > FreeBSD? I was going to wait until zfs-xattr.patch makes it in, since it is useless without the zfs-xattr.patch changes. I could do it sooner, if that makes things easier for people? Btw, I had the semantics for O_NAMEDATTR different from Solaris's O_XATTR, but that has been changed now. I also have a "runat" command. It can be found at.. https://people.freebsd.org/~rmacklem/runat.c rick > > Ced > -- > Cedric Blancher > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur From nobody Tue Apr 22 12:52: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 4Zhhvz3LHrz5sb3c for ; Tue, 22 Apr 2025 12:52:15 +0000 (UTC) (envelope-from SRS0=Az6a=XI=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4Zhhvy4HWwz40KH for ; Tue, 22 Apr 2025 12:52:14 +0000 (UTC) (envelope-from SRS0=Az6a=XI=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=YanbEUiq; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=Az6a=XI=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=Az6a=XI=klop.ws=ronald-lists@realworks.nl" Received: from crmpreview5.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview5.colo2.realworks.nl (Postfix) with ESMTP id ED01DC001C; Tue, 22 Apr 2025 14:52:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1745326332; 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=ClSQEPCr/B1V54VsbnCmdS93Ry2+HgE6CLmo0sJOo6k=; b=YanbEUiq0lxIVJAuMgWKUbqYknkji7m8PWP2gl75gEncaZMDVo5mn8UhWHWGlLmscMdZDB FjxfLwXC6I5ArBmRFIlHQvpMj5ntqpNukxTpz+Y+t4R1Ow/Lp6u+oTc9T/L6syshdfBtkx 73QqY+n6kB/CpkqH/eEW3Eqt7ifUc5OSaY49/WmbNJEKijoM0AXp0woV9S1QneFN7r6c8f xIjRDTc+fkImJuhhdXuEDg+DC7q/n6/KvhOOdGh9EfT7jMPdoUqXB6/4hhPSJXluz9oShT ZecCT+7KTskphH1zHh2NRqU/iWlzEwsjNyHx07GVRo+cN9XxW46SY4dAQ6wFhQ== Date: Tue, 22 Apr 2025 14:52:11 +0200 (CEST) From: Ronald Klop To: Sulev-Madis Silber Cc: freebsd-current Message-ID: <1357110019.7132.1745326331870@localhost> In-Reply-To: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> References: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> Subject: Re: zfs (?) issues? 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_7131_1729237935.1745326331763" X-Mailer: Realworks (746.12) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Result: default: False [1.53 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_SPAM_LONG(0.99)[0.992]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; MID_RHS_NOT_FQDN(0.50)[]; RBL_SENDERSCORE_REPUT_7(0.50)[194.109.157.24:from]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Az6a=XI=klop.ws=ronald-lists@realworks.nl]; ONCE_RECEIVED(0.20)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_ALLOW(0.00)[klop.ws:s=rw2]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; DKIM_TRACE(0.00)[klop.ws:+]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Az6a=XI=klop.ws=ronald-lists@realworks.nl]; DMARC_POLICY_ALLOW(0.00)[klop.ws,quarantine]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; R_SPF_ALLOW(0.00)[+ip4:194.109.157.0/24]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from] X-Rspamd-Queue-Id: 4Zhhvy4HWwz40KH X-Spamd-Bar: + ------=_Part_7131_1729237935.1745326331763 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, First, instead of writing "it gives vague errors", it really helps others on this list if you can copy-paste the errors into your email. Second, as far as I can see FreeBSD 13.4 uses OpenZFS 2.1.14. FreeBSD 14 uses OpenZFS 2.2.X which has bugfixes and improved tuning, although I cannot claim that will fix your issues. What you can try is to limit the growth of the ARC. Set "sysctl vfs.zfs.arc_max=1073741824" or add this to /etc/sysctl.conf to set the value at boot. This will limit the ARC to 1GB. I used similar settings on small machines without really noticing a speed difference while usability increased. You can play a bit with the value. Maybe 512MB will be even enough for your use case. NB: sysctl vfs.zfs.arc_max was renamed to vfs.zfs.arc.max with arc_max as a legacy alias, but I don't know if that already happened in 13.4. Another thing to check is the usage of tmpfs. If you don't restrict the max size of a tmpfs filesystem it will compete for memory. Although this will also show an increase in swap usage. Regards, Ronald. Van: Sulev-Madis Silber Datum: maandag, 21 april 2025 03:25 Aan: freebsd-current Onderwerp: zfs (?) issues? > > i have long running issue in my 13.4 box (amd64) > > others don't get it at all and only suggest adding more than 4g ram > > it manifests as some mmap or other problems i don't really get > > basically unrestricted git consumes all the memory. i had to turn watchdog on because something a git pull on ports tree causes kernel to take 100% of ram. it keeps killing userland off until it's just kernel running there happily. it never panics and killing off userland obviously makes the problem disappear and nothing will do any fs operations anymore > > dovecot without tuning or with some tuning tended to do this too > > what is it? > > now i noticed another issue. if i happen to do too many src git pulls in a row, they never actually "pull" anything. and / or clean my obj tree out. i can't run buildworld anymore. it gives vague errors > > if i wait a little before starting buildworld, it always works > > what could possibly happening here? the way the buildworld fails means there's serious issue with fs. and how could it be fixed with waiting? it means that some fs operations are still going on in background > > i have no idea what's happening here. zfs doesn't report any issues. nor do storage. nothing was killed with out of memory but arc usage somehow increased a lot. and it's compression ratio went weirdly high, like ~22:1 or so > > i don't know if it's acceptable zfs behaviour if it runs low on memory or not. how to test it. etc. and if this is fixed on 14, on stable, or on current. i don't have enough hw to test it on all > > i have done other stuff on that box that might also improper for amoung of ram i have there but then it's just slow, nothing fails like this > > unsure how this could be fixed or tuned or something else. or why does it behave like this. as opposed to usual low resource issues that just mean you need more time > > i mean it would be easy to add huge amounts of ram but people could also want to use zfs in slightly less powerful embedded systems where lack of power is expected but weird fails maybe not > > so is this a bug? a feature? something fixed? something that can't be fixed? what could be acceptable ram size? 8g? 16g? and why can't it just tune everything down and become slower as expected > > i tried to look up on any openzfs related bugs but zfs is huge and i'm not fs expert either > > i also don't know what happens while i wait. it doesn't show any serious io load. no cpu is taken. load is down. system is responsible > > it all feels like bug still > > i have wondered if this is second hand hw acting up but i checked and tested it as best as i could and why would it only bug out when i try more complex things on zfs? > > i'm curious about using zfs on super low memory systems too, because it offers certain features. maybe we could fix this if whole issue is ram. or if it's elsewhere, maybe that too > > i don't know what to think of this all. esp the last issue. i'm not really alone here with earlier issues but unsure > > > > ------=_Part_7131_1729237935.1745326331763 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

First, instead of writing "it gives vague errors", it really helps others on this list if you can copy-paste the errors into your email.

Second, as far as I can see FreeBSD 13.4 uses OpenZFS 2.1.14. FreeBSD 14 uses OpenZFS 2.2.X which has bugfixes and improved tuning, although I cannot claim that will fix your issues.
What you can try is to limit the growth of the ARC.

Set "sysctl vfs.zfs.arc_max=1073741824" or add this to /etc/sysctl.conf to set the value at boot.

This will limit the ARC to 1GB. I used similar settings on small machines without really noticing a speed difference while usability increased. You can play a bit with the value. Maybe 512MB will be even enough for your use case.

NB: sysctl vfs.zfs.arc_max was renamed to vfs.zfs.arc.max with arc_max as a legacy alias, but I don't know if that already happened in 13.4.

Another thing to check is the usage of tmpfs. If you don't restrict the max size of a tmpfs filesystem it will compete for memory. Although this will also show an increase in swap usage.

Regards,
Ronald.

 

Van: Sulev-Madis Silber <freebsd-current-freebsd-org111@ketas.si.pri.ee>
Datum: maandag, 21 april 2025 03:25
Aan: freebsd-current <freebsd-current@freebsd.org>
Onderwerp: zfs (?) issues?

i have long running issue in my 13.4 box (amd64)

others don't get it at all and only suggest adding more than 4g ram

it manifests as some mmap or other problems i don't really get

basically unrestricted git consumes all the memory. i had to turn watchdog on because something a git pull on ports tree causes kernel to take 100% of ram. it keeps killing userland off until it's just kernel running there happily. it never panics and killing off userland obviously makes the problem disappear and nothing will do any fs operations anymore

dovecot without tuning or with some tuning tended to do this too

what is it?

now i noticed another issue. if i happen to do too many src git pulls in a row, they never actually "pull" anything. and / or clean my obj tree out. i can't run buildworld anymore. it gives vague errors

if i wait a little before starting buildworld, it always works

what could possibly happening here? the way the buildworld fails means there's serious issue with fs. and how could it be fixed with waiting? it means that some fs operations are still going on in background

i have no idea what's happening here. zfs doesn't report any issues. nor do storage. nothing was killed with out of memory but arc usage somehow increased a lot. and it's compression ratio went weirdly high, like ~22:1 or so

i don't know if it's acceptable zfs behaviour if it runs low on memory or not. how to test it. etc. and if this is fixed on 14, on stable, or on current. i don't have enough hw to test it on all

i have done other stuff on that box that might also improper for amoung of ram i have there but then it's just slow, nothing fails like this

unsure how this could be fixed or tuned or something else. or why does it behave like this. as opposed to usual low resource issues that just mean you need more time

i mean it would be easy to add huge amounts of ram but people could also want to use zfs in slightly less powerful embedded systems where lack of power is expected but weird fails maybe not

so is this a bug? a feature? something fixed? something that can't be fixed? what could be acceptable ram size? 8g? 16g? and why can't it just tune everything down and become slower as expected

i tried to look up on any openzfs related bugs but zfs is huge and i'm not fs expert either

i also don't know what happens while i wait. it doesn't show any serious io load. no cpu is taken. load is down. system is responsible

it all feels like bug still

i have wondered if this is second hand hw acting up but i checked and tested it as best as i could and why would it only bug out when i try more complex things on zfs?

i'm curious about using zfs on super low memory systems too, because it offers certain features. maybe we could fix this if whole issue is ram. or if it's elsewhere, maybe that too

i don't know what to think of this all. esp the last issue. i'm not really alone here with earlier issues but unsure
 

  ------=_Part_7131_1729237935.1745326331763-- From nobody Tue Apr 22 15:23: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 4ZhmGM4DhGz5smfw for ; Tue, 22 Apr 2025 15:23:23 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4ZhmGL27f9z3Mb9 for ; Tue, 22 Apr 2025 15:23:21 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=NN6FqZB5; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1745335385; bh=F/lCtOz3Xd6i9Gx+/77hnb6JsIaKuKY6FmZkPIBaRPs=; h=Date:From:To:Subject:In-Reply-To:References; b=NN6FqZB51SLIlei9QlOH10QXi1WwEjh9nJIdsz3kJeKBKHBpPHTgtIDmbE5xtWJwo izIfcef7XgUTv6khzRPEwddYd0X5BR6Aa4xDZ68wnMJ8dWN8/IK9Ty+ar8AA60TXCl SMVvN0B6+FRf7nQBH3HHnZJBal/l77N5ifANrDTqIzeE4GkXKK9n2ABEDHF5jnrShe gBzA4rlHE97cSFkVGS613HhXBWwsYUx8Aa02h0yIA1HlLg008qnevMvaqF/jXwEMZb 8KswXfxAZU2EVaOeVK9H55Ix1Yqem4l5C419lbv/WhnF1z2n3wWPzN9wOc4iDApQoP YPrz1pluoawSKdi7b44OouSGDvKIc7GsRB0QWHFmSAGR4rLY+HDLui4GuSohOqqm94 LyUgme8Q5o/3yhNbYLswyy/Tp4/D/2j/dcBdJft02MPg1FwsCn0XzT91/jXp7D+jZG WmsNWep8od4E/F7gXQl5P6ZEVfL8TjFpaG2i6+TNwG2vnTcOzIGPIA+kwKAVB+ckss gNOIzGX4UAum0xLP29LD4lmRtHDWsapwiW/iQ8Tsnyfj+7vZxBAW+Kwh3l1Gh7xMvp im97HvbhIS6AYZTccmEa8+1xiy7Sx7dp0KyJ55bT8QHS4vyDBNnsDHa2bojdJSDYnX phr1ReCpCzzQLJJof7JP461w= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id C81635B10E1 for ; Tue, 22 Apr 2025 18:23:04 +0300 (EEST) Date: Tue, 22 Apr 2025 18:23:03 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: zfs (?) issues? User-Agent: K-9 Mail for Android In-Reply-To: <1357110019.7132.1745326331870@localhost> References: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> <1357110019.7132.1745326331870@localhost> 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-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [2.42 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.954]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_SPAM_LONG(0.42)[0.421]; NEURAL_HAM_SHORT(-0.24)[-0.244]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(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)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4ZhmGL27f9z3Mb9 X-Spamd-Bar: ++ well i don't have those errors anymore so there's nothing to give i've tried to tune arc but it didn't do anything so i took those things of= f again right now i'm looking at ARC: 1487M Total, 1102M MFU, 128M MRU, 1544K Anon, 56M Header, 199M Other 942M Compressed, 18G Uncompressed, 19=2E36:1 Ratio and wonder wtf i bet there's issue somewhere and i somehow can't properly recreate it=2E = on memory pressure it does resize arc down properly so seems like i don't n= eed any limits and there's no tmpfs=2E it would be useless at that low memory sizes the problem is that i can't figure out what all those problems are, how to= recreate those conditions and how to workaround or maybe find bugs=2E also= don't have enough hw to solely test it on=2E unless i can maybe try it on = tiny 512m vm=2E and then i would need to know what to try i also don't know why those git settings help me: [core] packedGitWindowSize =3D 32m packedGitLimit =3D 128m preloadIndex =3D false [diff] renameLimit =3D 16384 how to tune it from some global place=2E and so on=2E and why it would eve= n need fiddiling so much? zfs indeed has improved a lot, previously it was = quite a hell to use i don't even know if this is related to mmap=2E even then, i don't really = get what that function even does=2E hence then "zfs (?) issue"=2E it might = even not be zfs at all there are probably multiple combined issues here i also don't really buy the idea that ton of ram would automatically fix t= his so yeah unsure what to think of this some of the issues i found that others also have=2E some of them seem new some fixes were like as if trial and errors and nobody seemed to know what= 's wrong even=2E granted, that was forum so maybe here it's better here? i mean i have used below average equipment my entire life and usual case t= o cope with this is to just give it more time=2E put more swap and just wai= t i think someone tested my git issues in 4g vm and found no issues at all? = other things seem like as i only i have them i also find kind of confusing that if this is hw, why i don't see any othe= r issues this is not the first time that i have found something confusing in fbsd t= hat later turned out to be bug and was further tested and fixed by other hence the current mailing list so maybe someone else has ideas=2E or if it= has already fix=2E and i hope there are people with much larger labs and c= ould easily tell / test things so in the end, 1) why should git on large repo cause machine to run out of memory, instea= d of just being as slow as it would need to be 2) why / what are fs operations that could cause low power machine to myst= eriously fail on zfs, when expected results would be slow fs behaviour i don't know what really happens and it's way too complex me to get all me= mory management that happens in kernel=2E i only have this wild guess that = any type of caching should happen in "leftover" ram and make things faster = if possible=2E and any fs operations that have already reported completed b= y kernel can't be suddenly found incomplete later=2E whatever that fs-relat= ed stray buildworld error was that resolved itself somehow=2E and what i ca= n recreate and i'm not expert in this so how do i even know? what's fun is how running rsync over several tb's of data doesn't seem to = cause any issues at all=2E this is still same machine, many would not recom= mend using this=2E different workload? hell knows what's all this=2E maybe later i could figure it out or actuall= y save some logs or=2E those i didn't save as i assumed it repeats itself= =2E didn't and it went off tmux window history oh well=2E yes, this is questionable report but those are "heisenbugs" as = well=2E at least some? On April 22, 2025 3:52:11 PM GMT+03:00, Ronald Klop wrote: >Hi, > >First, instead of writing "it gives vague errors", it really helps others= on this list if you can copy-paste the errors into your email=2E > >Second, as far as I can see FreeBSD 13=2E4 uses OpenZFS 2=2E1=2E14=2E Fre= eBSD 14 uses OpenZFS 2=2E2=2EX which has bugfixes and improved tuning, alth= ough I cannot claim that will fix your issues=2E >What you can try is to limit the growth of the ARC=2E > >Set "sysctl vfs=2Ezfs=2Earc_max=3D1073741824" or add this to /etc/sysctl= =2Econf to set the value at boot=2E > >This will limit the ARC to 1GB=2E I used similar settings on small machin= es without really noticing a speed difference while usability increased=2E = You can play a bit with the value=2E Maybe 512MB will be even enough for yo= ur use case=2E > >NB: sysctl vfs=2Ezfs=2Earc_max was renamed to vfs=2Ezfs=2Earc=2Emax with = arc_max as a legacy alias, but I don't know if that already happened in 13= =2E4=2E > >Another thing to check is the usage of tmpfs=2E If you don't restrict the= max size of a tmpfs filesystem it will compete for memory=2E Although this= will also show an increase in swap usage=2E > >Regards, >Ronald=2E > > >Van: Sulev-Madis Silber >Datum: maandag, 21 april 2025 03:25 >Aan: freebsd-current >Onderwerp: zfs (?) issues? >>=20 >> i have long running issue in my 13=2E4 box (amd64) >>=20 >> others don't get it at all and only suggest adding more than 4g ram >>=20 >> it manifests as some mmap or other problems i don't really get >>=20 >> basically unrestricted git consumes all the memory=2E i had to turn wat= chdog on because something a git pull on ports tree causes kernel to take 1= 00% of ram=2E it keeps killing userland off until it's just kernel running = there happily=2E it never panics and killing off userland obviously makes t= he problem disappear and nothing will do any fs operations anymore >>=20 >> dovecot without tuning or with some tuning tended to do this too >>=20 >> what is it? >>=20 >> now i noticed another issue=2E if i happen to do too many src git pulls= in a row, they never actually "pull" anything=2E and / or clean my obj tre= e out=2E i can't run buildworld anymore=2E it gives vague errors >>=20 >> if i wait a little before starting buildworld, it always works >>=20 >> what could possibly happening here? the way the buildworld fails means = there's serious issue with fs=2E and how could it be fixed with waiting? it= means that some fs operations are still going on in background >>=20 >> i have no idea what's happening here=2E zfs doesn't report any issues= =2E nor do storage=2E nothing was killed with out of memory but arc usage s= omehow increased a lot=2E and it's compression ratio went weirdly high, lik= e ~22:1 or so >>=20 >> i don't know if it's acceptable zfs behaviour if it runs low on memory = or not=2E how to test it=2E etc=2E and if this is fixed on 14, on stable, o= r on current=2E i don't have enough hw to test it on all >>=20 >> i have done other stuff on that box that might also improper for amoung= of ram i have there but then it's just slow, nothing fails like this >>=20 >> unsure how this could be fixed or tuned or something else=2E or why doe= s it behave like this=2E as opposed to usual low resource issues that just = mean you need more time >>=20 >> i mean it would be easy to add huge amounts of ram but people could als= o want to use zfs in slightly less powerful embedded systems where lack of = power is expected but weird fails maybe not >>=20 >> so is this a bug? a feature? something fixed? something that can't be f= ixed? what could be acceptable ram size? 8g? 16g? and why can't it just tun= e everything down and become slower as expected >>=20 >> i tried to look up on any openzfs related bugs but zfs is huge and i'm = not fs expert either >>=20 >> i also don't know what happens while i wait=2E it doesn't show any seri= ous io load=2E no cpu is taken=2E load is down=2E system is responsible >>=20 >> it all feels like bug still >>=20 >> i have wondered if this is second hand hw acting up but i checked and t= ested it as best as i could and why would it only bug out when i try more c= omplex things on zfs? >>=20 >> i'm curious about using zfs on super low memory systems too, because it= offers certain features=2E maybe we could fix this if whole issue is ram= =2E or if it's elsewhere, maybe that too >>=20 >> i don't know what to think of this all=2E esp the last issue=2E i'm not= really alone here with earlier issues but unsure >> =20 >>=20 >>=20 > From nobody Tue Apr 22 15:49:43 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zhms166qFz5snxf for ; Tue, 22 Apr 2025 15:49:57 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zhms145Bdz3ZZt for ; Tue, 22 Apr 2025 15:49:57 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5f435c9f2f9so8139320a12.1 for ; Tue, 22 Apr 2025 08:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745336996; x=1745941796; 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=MImSsogORdjYUlPCWyoeyTLoi8jA2jbqbrVQS5LqjY0=; b=KHxXrH13VOnHcosIjk27RYcnUYu/GVzv5Mm6hETllse3XUGk7wDydTk83yR1I5/Gtu JY80kQPvpg+QBaAJ0JsQdk5HMnQbX7OoXNsJcw6cpdySxq69I0hyjSnJMjSkJQ9VDpbD JKLXrb67PVT7KMPzcS01zd9keMZ2mimlGyCUfygeUrpHmtolj1cm51cHRJv8hWKniqhK KVeJtYAZVMAYbKa12uyg2UbznlAwYCs63cjd8DH6iHe+nEO/scz477m1EuqEKk/B90aP JaXNWBB94/+bminfuqOXq0oSxvPo9QzjF30cPqjToyr2rmoDe8Eqvk/HBg8k2gPmZtwj 291g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745336996; x=1745941796; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MImSsogORdjYUlPCWyoeyTLoi8jA2jbqbrVQS5LqjY0=; b=gWKVvFsqgIpYN3qInC4nth8vZqjkpfDRZdy+PdoiyE68KY5gSDoCwapsSCFcLI4h/Z FX5AnextYLArNGYn657NDOgtTR+eq8UNOtW3JAu9Ko/6oYlj5OpOg214p8AaV4rmfYfF 6Q01rgM4nQr7vS3jRj4tERMuiBh/W6yO7S+sAdzpMf3NzQo6xI78CCS2BSAdYbgOdc0y GW1xSNJOBri3s0YZhcYocCi6mdrbgDbIISlf5zXAQo6btYtCWIYK+Quhl24gX2uizLop csetHtiVWyydqH0olJyhymwxpkqINW8WXaSzI2QAY0EeIH5l6dpDKXLWHK0EICoVwai/ 9DtQ== X-Gm-Message-State: AOJu0Yx6YIjdlCGSxVQ4u/r4dD3sKGqO1PsEhrNQEil7FOipk7b2AVz8 mHzU5BeKe/qNRZlfpDS/I6X9wgy5ndGHo5mPL+YNtgPXepk7sSKfdXGI9PkYX2DWGoAs3dbe4K+ jKp/UempTviA+8EDUcZbNOYvCFQ== X-Gm-Gg: ASbGncsv72YXkKt7DL48R8cAb0/RnB+hve5MBYwsu3pDKQoXLdI1BmQlqUUS2sifN1h Wre7lv7oE5Zx3lLxUOcVudmOD53OppJ0APi8O+YUTn79kw7JlxhVrrK01UsOCl6Dlh50T7ujqg9 /XcDpm27Pmo3A3b1Le7fjkjIBcIlniRGjWoNOwvhhOUWT0yZR330kq+A== X-Google-Smtp-Source: AGHT+IE42lLh11i2LbRDX+GrrXmYQwTTaGmb9t1htPLSjPFB47PG7Li4iDJvDiSqH5h4+TdBp5yw34LrOe6tcryi6AA= X-Received: by 2002:a05:6402:5241:b0:5e5:3643:c8b5 with SMTP id 4fb4d7f45d1cf-5f628612e4cmr15193725a12.30.1745336995564; Tue, 22 Apr 2025 08:49:55 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> <1357110019.7132.1745326331870@localhost> In-Reply-To: From: Rick Macklem Date: Tue, 22 Apr 2025 08:49:43 -0700 X-Gm-Features: ATxdqUFM1-WDEqJfg7ZFm7dVFD8GJZKn0eo8wVJ47poqmS2qaiOOSorlp-4Lqhw Message-ID: Subject: Re: zfs (?) issues? To: Sulev-Madis Silber Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Zhms145Bdz3ZZt X-Spamd-Bar: ---- I wouldn't normally top post, but all I have is a generic question. Do you have a swap partition setup? (I'd use something like 6-8Gbytes for a 4Gbyte system.) rick On Tue, Apr 22, 2025 at 8:23=E2=80=AFAM Sulev-Madis Silber wrote: > > well i don't have those errors anymore so there's nothing to give > > i've tried to tune arc but it didn't do anything so i took those things o= ff again > > right now i'm looking at > > ARC: 1487M Total, 1102M MFU, 128M MRU, 1544K Anon, 56M Header, 199M Other > 942M Compressed, 18G Uncompressed, 19.36:1 Ratio > > and wonder wtf > > i bet there's issue somewhere and i somehow can't properly recreate it. o= n memory pressure it does resize arc down properly so seems like i don't ne= ed any limits > > and there's no tmpfs. it would be useless at that low memory sizes > > the problem is that i can't figure out what all those problems are, how t= o recreate those conditions and how to workaround or maybe find bugs. also = don't have enough hw to solely test it on. unless i can maybe try it on tin= y 512m vm. and then i would need to know what to try > > i also don't know why those git settings help me: > > [core] > packedGitWindowSize =3D 32m > packedGitLimit =3D 128m > preloadIndex =3D false > [diff] > renameLimit =3D 16384 > > how to tune it from some global place. and so on. and why it would even n= eed fiddiling so much? zfs indeed has improved a lot, previously it was qui= te a hell to use > > i don't even know if this is related to mmap. even then, i don't really g= et what that function even does. hence then "zfs (?) issue". it might even = not be zfs at all > > there are probably multiple combined issues here > > i also don't really buy the idea that ton of ram would automatically fix = this > > so yeah unsure what to think of this > > some of the issues i found that others also have. some of them seem new > > some fixes were like as if trial and errors and nobody seemed to know wha= t's wrong even. granted, that was forum so maybe here it's better here? > > i mean i have used below average equipment my entire life and usual case = to cope with this is to just give it more time. put more swap and just wait > > i think someone tested my git issues in 4g vm and found no issues at all?= other things seem like as i only i have them > > i also find kind of confusing that if this is hw, why i don't see any oth= er issues > > this is not the first time that i have found something confusing in fbsd = that later turned out to be bug and was further tested and fixed by other > > hence the current mailing list so maybe someone else has ideas. or if it = has already fix. and i hope there are people with much larger labs and coul= d easily tell / test things > > so in the end, > > 1) why should git on large repo cause machine to run out of memory, inste= ad of just being as slow as it would need to be > > 2) why / what are fs operations that could cause low power machine to mys= teriously fail on zfs, when expected results would be slow fs behaviour > > i don't know what really happens and it's way too complex me to get all m= emory management that happens in kernel. i only have this wild guess that a= ny type of caching should happen in "leftover" ram and make things faster i= f possible. and any fs operations that have already reported completed by k= ernel can't be suddenly found incomplete later. whatever that fs-related st= ray buildworld error was that resolved itself somehow. and what i can recre= ate > > and i'm not expert in this so how do i even know? > > what's fun is how running rsync over several tb's of data doesn't seem to= cause any issues at all. this is still same machine, many would not recomm= end using this. different workload? > > hell knows what's all this. maybe later i could figure it out or actually= save some logs or. those i didn't save as i assumed it repeats itself. did= n't and it went off tmux window history > > oh well. yes, this is questionable report but those are "heisenbugs" as w= ell. at least some? > > > > On April 22, 2025 3:52:11 PM GMT+03:00, Ronald Klop wrote: > >Hi, > > > >First, instead of writing "it gives vague errors", it really helps other= s on this list if you can copy-paste the errors into your email. > > > >Second, as far as I can see FreeBSD 13.4 uses OpenZFS 2.1.14. FreeBSD 14= uses OpenZFS 2.2.X which has bugfixes and improved tuning, although I cann= ot claim that will fix your issues. > >What you can try is to limit the growth of the ARC. > > > >Set "sysctl vfs.zfs.arc_max=3D1073741824" or add this to /etc/sysctl.con= f to set the value at boot. > > > >This will limit the ARC to 1GB. I used similar settings on small machine= s without really noticing a speed difference while usability increased. You= can play a bit with the value. Maybe 512MB will be even enough for your us= e case. > > > >NB: sysctl vfs.zfs.arc_max was renamed to vfs.zfs.arc.max with arc_max a= s a legacy alias, but I don't know if that already happened in 13.4. > > > >Another thing to check is the usage of tmpfs. If you don't restrict the = max size of a tmpfs filesystem it will compete for memory. Although this wi= ll also show an increase in swap usage. > > > >Regards, > >Ronald. > > > > > >Van: Sulev-Madis Silber > >Datum: maandag, 21 april 2025 03:25 > >Aan: freebsd-current > >Onderwerp: zfs (?) issues? > >> > >> i have long running issue in my 13.4 box (amd64) > >> > >> others don't get it at all and only suggest adding more than 4g ram > >> > >> it manifests as some mmap or other problems i don't really get > >> > >> basically unrestricted git consumes all the memory. i had to turn watc= hdog on because something a git pull on ports tree causes kernel to take 10= 0% of ram. it keeps killing userland off until it's just kernel running the= re happily. it never panics and killing off userland obviously makes the pr= oblem disappear and nothing will do any fs operations anymore > >> > >> dovecot without tuning or with some tuning tended to do this too > >> > >> what is it? > >> > >> now i noticed another issue. if i happen to do too many src git pulls = in a row, they never actually "pull" anything. and / or clean my obj tree o= ut. i can't run buildworld anymore. it gives vague errors > >> > >> if i wait a little before starting buildworld, it always works > >> > >> what could possibly happening here? the way the buildworld fails means= there's serious issue with fs. and how could it be fixed with waiting? it = means that some fs operations are still going on in background > >> > >> i have no idea what's happening here. zfs doesn't report any issues. n= or do storage. nothing was killed with out of memory but arc usage somehow = increased a lot. and it's compression ratio went weirdly high, like ~22:1 o= r so > >> > >> i don't know if it's acceptable zfs behaviour if it runs low on memory= or not. how to test it. etc. and if this is fixed on 14, on stable, or on = current. i don't have enough hw to test it on all > >> > >> i have done other stuff on that box that might also improper for amoun= g of ram i have there but then it's just slow, nothing fails like this > >> > >> unsure how this could be fixed or tuned or something else. or why does= it behave like this. as opposed to usual low resource issues that just mea= n you need more time > >> > >> i mean it would be easy to add huge amounts of ram but people could al= so want to use zfs in slightly less powerful embedded systems where lack of= power is expected but weird fails maybe not > >> > >> so is this a bug? a feature? something fixed? something that can't be = fixed? what could be acceptable ram size? 8g? 16g? and why can't it just tu= ne everything down and become slower as expected > >> > >> i tried to look up on any openzfs related bugs but zfs is huge and i'm= not fs expert either > >> > >> i also don't know what happens while i wait. it doesn't show any serio= us io load. no cpu is taken. load is down. system is responsible > >> > >> it all feels like bug still > >> > >> i have wondered if this is second hand hw acting up but i checked and = tested it as best as i could and why would it only bug out when i try more = complex things on zfs? > >> > >> i'm curious about using zfs on super low memory systems too, because i= t offers certain features. maybe we could fix this if whole issue is ram. o= r if it's elsewhere, maybe that too > >> > >> i don't know what to think of this all. esp the last issue. i'm not re= ally alone here with earlier issues but unsure > >> > >> > >> > > > From nobody Tue Apr 22 17:34:35 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZhqB43Ffxz5sx3L for ; Tue, 22 Apr 2025 17:34:52 +0000 (UTC) (envelope-from tsoome@me.com) Received: from outbound.ci.icloud.com (p-east1-cluster4-host2-snip6-10.eps.apple.com [IPv6:2a01:b747:3005:204::17]) (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 4ZhqB23syCz3MxF for ; Tue, 22 Apr 2025 17:34:50 +0000 (UTC) (envelope-from tsoome@me.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=me.com header.s=1a1hai header.b=BPgdy37f; dmarc=pass (policy=quarantine) header.from=me.com; spf=pass (mx1.freebsd.org: domain of tsoome@me.com designates 2a01:b747:3005:204::17 as permitted sender) smtp.mailfrom=tsoome@me.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; bh=17J9dDsyvU9I+vuTa8f51G8LhDOPgBRyKkAXFZUs+34=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id:x-icloud-hme; b=BPgdy37fPBIBAEOpZjsOde2M837V1YNmjlzYuK/UWND/FmcIev/XvoTSSl51td29R ZdeGpWwsnsVx8zAAWGSIRzeNAX9JQgLxeGZkwH2yiIiDwjorHUvpT+9aT2IWxTxRfE h+IKQLHWG3AZyat5EW5GqvjejkewGZ6VQC+x66QWYM05TIDxuci2gLGjT26UVGMnbA XmaFwWcvDiL6U0DE+V9kGgZpdhT5+KP+GiHLGWWJCG4TnjnsEGMwAO0DKPOh3kXKsC Ffws6JaU2MDGIMEVhLJF4bFuzyos/4mxYzidek/egZIONf77s17naAtUZAelMntYnb AVjrwjVr+RdCw== Received: from smtpclient.apple (ci-asmtp-me-k8s.p00.prod.me.com [17.57.156.36]) by outbound.ci.icloud.com (Postfix) with ESMTPSA id B02C11804D30 for ; Tue, 22 Apr 2025 17:34:46 +0000 (UTC) From: Toomas Soome 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.500.181.1.5\)) Subject: Re: zfs (?) issues? Date: Tue, 22 Apr 2025 20:34:35 +0300 References: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> <1357110019.7132.1745326331870@localhost> To: freebsd-current@freebsd.org In-Reply-To: Message-Id: <1A4907E8-315F-4A34-95F6-E6A184B9DCC8@me.com> X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Proofpoint-ORIG-GUID: b4oEYedT9LQBx91bO65LWLhxQpcURqH_ X-Proofpoint-GUID: b4oEYedT9LQBx91bO65LWLhxQpcURqH_ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1095,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-04-22_08,2025-04-22_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 mlxlogscore=999 clxscore=1015 mlxscore=0 suspectscore=0 adultscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2504220132 X-Spamd-Result: default: False [2.97 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.95)[0.954]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_SPAM_SHORT(0.32)[0.318]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:b747:3005:200::/56]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[me.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[me.com]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:714, ipnet:2a01:b747::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEFALL_USER(0.00)[tsoome]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; RCVD_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[me.com:+]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZhqB23syCz3MxF X-Spamd-Bar: ++ > On 22. Apr 2025, at 18:23, Sulev-Madis Silber = wrote: >=20 > well i don't have those errors anymore so there's nothing to give >=20 > i've tried to tune arc but it didn't do anything so i took those = things off again >=20 > right now i'm looking at >=20 > ARC: 1487M Total, 1102M MFU, 128M MRU, 1544K Anon, 56M Header, 199M = Other > 942M Compressed, 18G Uncompressed, 19.36:1 Ratio >=20 > and wonder wtf >=20 > i bet there's issue somewhere and i somehow can't properly recreate = it. on memory pressure it does resize arc down properly so seems like i = don't need any limits >=20 > and there's no tmpfs. it would be useless at that low memory sizes >=20 > the problem is that i can't figure out what all those problems are, = how to recreate those conditions and how to workaround or maybe find = bugs. also don't have enough hw to solely test it on. unless i can maybe = try it on tiny 512m vm. and then i would need to know what to try >=20 > i also don't know why those git settings help me: >=20 > [core] > packedGitWindowSize =3D 32m > packedGitLimit =3D 128m > preloadIndex =3D false > [diff] > renameLimit =3D 16384 >=20 > how to tune it from some global place. and so on. and why it would = even need fiddiling so much? zfs indeed has improved a lot, previously = it was quite a hell to use >=20 > i don't even know if this is related to mmap. even then, i don't = really get what that function even does. hence then "zfs (?) issue". it = might even not be zfs at all >=20 > there are probably multiple combined issues here >=20 > i also don't really buy the idea that ton of ram would automatically = fix this >=20 > so yeah unsure what to think of this >=20 > some of the issues i found that others also have. some of them seem = new >=20 > some fixes were like as if trial and errors and nobody seemed to know = what's wrong even. granted, that was forum so maybe here it's better = here? >=20 > i mean i have used below average equipment my entire life and usual = case to cope with this is to just give it more time. put more swap and = just wait >=20 > i think someone tested my git issues in 4g vm and found no issues at = all? other things seem like as i only i have them >=20 > i also find kind of confusing that if this is hw, why i don't see any = other issues >=20 > this is not the first time that i have found something confusing in = fbsd that later turned out to be bug and was further tested and fixed by = other >=20 > hence the current mailing list so maybe someone else has ideas. or if = it has already fix. and i hope there are people with much larger labs = and could easily tell / test things >=20 > so in the end, >=20 > 1) why should git on large repo cause machine to run out of memory, = instead of just being as slow as it would need to be um, because it is buggy? Or pick some other fun reason, because the this = wording does not really make much sense. >=20 > 2) why / what are fs operations that could cause low power machine to = mysteriously fail on zfs, when expected results would be slow fs = behaviour >=20 define low power? in general, the failures on system with limited = resources hint about lack of testing and bug hunting in such systems. = Over time, there have been improvements, but this is almost never ending = task. > i don't know what really happens and it's way too complex me to get = all memory management that happens in kernel. i only have this wild = guess that any type of caching should happen in "leftover" ram and make = things faster if possible. and any fs operations that have already = reported completed by kernel can't be suddenly found incomplete later. = whatever that fs-related stray buildworld error was that resolved itself = somehow. and what i can recreate >=20 default fs operations are asynchronous, if you want them to be = =E2=80=9Ccomplete=E2=80=9D, that is, data on stable storage and = consistent state for file system, you need synchronous IO. But as = always, there is price to pay. > and i'm not expert in this so how do i even know? >=20 > what's fun is how running rsync over several tb's of data doesn't seem = to cause any issues at all. this is still same machine, many would not = recommend using this. different workload? >=20 If you are comparing git with rsync, you want to make sure you have up = to date git. There are git versions with rather nasty bugs. > hell knows what's all this. maybe later i could figure it out or = actually save some logs or. those i didn't save as i assumed it repeats = itself. didn't and it went off tmux window history >=20 > oh well. yes, this is questionable report but those are "heisenbugs" = as well. at least some? >=20 Heisenbug is bug for which we do not yet know the trigger mechanism, it = does not mean they do not have such mechanism. rgds, toomas >=20 >=20 > On April 22, 2025 3:52:11 PM GMT+03:00, Ronald Klop = wrote: >> Hi, >>=20 >> First, instead of writing "it gives vague errors", it really helps = others on this list if you can copy-paste the errors into your email. >>=20 >> Second, as far as I can see FreeBSD 13.4 uses OpenZFS 2.1.14. FreeBSD = 14 uses OpenZFS 2.2.X which has bugfixes and improved tuning, although I = cannot claim that will fix your issues. >> What you can try is to limit the growth of the ARC. >>=20 >> Set "sysctl vfs.zfs.arc_max=3D1073741824" or add this to = /etc/sysctl.conf to set the value at boot. >>=20 >> This will limit the ARC to 1GB. I used similar settings on small = machines without really noticing a speed difference while usability = increased. You can play a bit with the value. Maybe 512MB will be even = enough for your use case. >>=20 >> NB: sysctl vfs.zfs.arc_max was renamed to vfs.zfs.arc.max with = arc_max as a legacy alias, but I don't know if that already happened in = 13.4. >>=20 >> Another thing to check is the usage of tmpfs. If you don't restrict = the max size of a tmpfs filesystem it will compete for memory. Although = this will also show an increase in swap usage. >>=20 >> Regards, >> Ronald. >>=20 >>=20 >> Van: Sulev-Madis Silber = >> Datum: maandag, 21 april 2025 03:25 >> Aan: freebsd-current >> Onderwerp: zfs (?) issues? >>>=20 >>> i have long running issue in my 13.4 box (amd64) >>>=20 >>> others don't get it at all and only suggest adding more than 4g ram >>>=20 >>> it manifests as some mmap or other problems i don't really get >>>=20 >>> basically unrestricted git consumes all the memory. i had to turn = watchdog on because something a git pull on ports tree causes kernel to = take 100% of ram. it keeps killing userland off until it's just kernel = running there happily. it never panics and killing off userland = obviously makes the problem disappear and nothing will do any fs = operations anymore >>>=20 >>> dovecot without tuning or with some tuning tended to do this too >>>=20 >>> what is it? >>>=20 >>> now i noticed another issue. if i happen to do too many src git = pulls in a row, they never actually "pull" anything. and / or clean my = obj tree out. i can't run buildworld anymore. it gives vague errors >>>=20 >>> if i wait a little before starting buildworld, it always works >>>=20 >>> what could possibly happening here? the way the buildworld fails = means there's serious issue with fs. and how could it be fixed with = waiting? it means that some fs operations are still going on in = background >>>=20 >>> i have no idea what's happening here. zfs doesn't report any issues. = nor do storage. nothing was killed with out of memory but arc usage = somehow increased a lot. and it's compression ratio went weirdly high, = like ~22:1 or so >>>=20 >>> i don't know if it's acceptable zfs behaviour if it runs low on = memory or not. how to test it. etc. and if this is fixed on 14, on = stable, or on current. i don't have enough hw to test it on all >>>=20 >>> i have done other stuff on that box that might also improper for = amoung of ram i have there but then it's just slow, nothing fails like = this >>>=20 >>> unsure how this could be fixed or tuned or something else. or why = does it behave like this. as opposed to usual low resource issues that = just mean you need more time >>>=20 >>> i mean it would be easy to add huge amounts of ram but people could = also want to use zfs in slightly less powerful embedded systems where = lack of power is expected but weird fails maybe not >>>=20 >>> so is this a bug? a feature? something fixed? something that can't = be fixed? what could be acceptable ram size? 8g? 16g? and why can't it = just tune everything down and become slower as expected >>>=20 >>> i tried to look up on any openzfs related bugs but zfs is huge and = i'm not fs expert either >>>=20 >>> i also don't know what happens while i wait. it doesn't show any = serious io load. no cpu is taken. load is down. system is responsible >>>=20 >>> it all feels like bug still >>>=20 >>> i have wondered if this is second hand hw acting up but i checked = and tested it as best as i could and why would it only bug out when i = try more complex things on zfs? >>>=20 >>> i'm curious about using zfs on super low memory systems too, because = it offers certain features. maybe we could fix this if whole issue is = ram. or if it's elsewhere, maybe that too >>>=20 >>> i don't know what to think of this all. esp the last issue. i'm not = really alone here with earlier issues but unsure >>>=20 >>>=20 >>>=20 >>=20 >=20 From nobody Wed Apr 23 02:04:28 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 4Zj2VH3H8Wz5tXm3 for ; Wed, 23 Apr 2025 02:04:39 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4Zj2VG1HQ3z47lW for ; Wed, 23 Apr 2025 02:04:37 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=NHxNZH6v; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1745373869; bh=i4X4VxNy4qa7sKc6eJRNsuYl7LZN6UmRNkAwRFfNvsg=; h=Date:From:To:Subject:In-Reply-To:References; b=NHxNZH6vaWEiWkkryRytuXYcOmn5s1DUwCLM1+gkSr4JtvdAaFlIUlpqgBRt/ikTY 4B4MV9YZ7BsLXxsJS4XTKtpZ419QQ4v1G6EXTqL53tG62Gf5Wg7wmnIGBhXHgU6Fo5 3FJ3i2WkQbs6D9RvEIc8PgFVwXykW2jMBtZZFUP0AIGFYQ0H6otKWkGg0F50vBnUFw 5uvz8AuCoKORHNb9k+/bdV55AMrZYkdZRA1v1C5uccgZ6fnXLsL6iB9De94mAzfxsr X/nTk8tLDxHl1P/QZQG1sgFgVXjcwViBlBb35lxr1OuR85k9kBGVSe98yuko5i0srg qdidt4ME5ZIDkQGG33uyzeQOM1ySHnSP7cduodJhHOHez/6Uq+F8LDPE7Mh2NavrnQ HC6Is7E5cgFqYdPNT5o33miYQPRFhl99Q4cEodF2J64/ZgUNF+OmhinF2IBLYTcddC jez5MMt2QbfiALMGGWXjq2J93sVQTscPp7RWgA417gniJbb/it57gdn+OqdKqcIxAX kGW9dSh2qbni1sg89spvGSEAii4gOhnMZBYf3TMtWiA6A/tZsZD5lIcuX6T/v2YBCl Wrg96BlVtuYJUT2WUbqFrlpOXD3qk91lYTaIVDM75TocpJQpidyWNxn5U9She7dGA0 ZO1b4fwK/5r7u4yO+CSft+IM= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id D79F95B3436 for ; Wed, 23 Apr 2025 05:04:29 +0300 (EEST) Date: Wed, 23 Apr 2025 05:04:28 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: zfs (?) issues? User-Agent: K-9 Mail for Android In-Reply-To: References: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> <1357110019.7132.1745326331870@localhost> Message-ID: <2E9A6E62-85CA-4C34-A22E-15A8EACB83EC@ketas.si.pri.ee> 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-Spamd-Result: default: False [1.97 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.988]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_HAM_LONG(-0.24)[-0.238]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.00)[0.001]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(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)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4Zj2VG1HQ3z47lW X-Spamd-Bar: + yes, 2 * 8g partitions on separate disks, so i have 16g swap but issues i see aren't "usual" memory problems=2E even building rust work= s, just takes 10g swap and entire day=2E nothing will fail=2E nothing will = lag but what i see are kernel taking too much=2E as far as i understand=2E i c= an't figure out when and how it all seems to originate from git=2E but what could it possibly do that m= akes it a perfect stress test tool? number of files in single directory? fi= le size? count? type of access method and speed of those calls? order? basically don't touch git, esp=2E large repos but then dovecot, also running there, also nearly caused similar issues=2E= all i know is a maildirs are also ton of small files i don't know what's happening and should it or not during earlier tests with git on ports tree which had ton of changes, i ob= served that arc was quite low but wired went super high super fast=2E nothi= ng was swapped out iirc that was unswappable kernel memory of a kind funnily=2E git without limits took machine down but git with limits had no= real speed reduction while not taking it down i tried to even figure out where kernel memory might be going but couldn't= figure it out either=2E it seemed to like have normal small usage for each= part, including zfs i wonder what's the best way to look into that? and is this expected or not=2E i don't know! the question of swap would be good if i would run out of memory in userl= and or so unsure what runs out=2E maybe it's even fine=2E but i refuse to believe it= 's expected? unsure if it could even be fixed without zfs performance being also affect= ed=2E there are also massive servers and people would be pissed if puny lit= tle box issues affect them=2E but why it can't be dynamic or so? i recall zfs being worse before=2E first it required ton of ram=2E like 4g= min=2E 10y ago and so=2E then this was somehow reduced=2E then r/w speed w= as low, like 40mb/s=2E then it was fixed too=2E what's this now? how to like even figure out what kind of memory is exhausted? and why woul= d i need to tune any of this=2E as system would know what's installed ram s= ize i kind of have troubles imagining a system where whole ram goes to kernel= =2E maybe there is i tried to look what else besides arc could be limited but couldn't find a= ny=2E don't even know what happens all i know this isn't usual case of ram runs low, everything grinds to hal= t until things swap out and eventually get killed i even tested that=2E if i specifically try to allocate ton of memory from= userland, arc reduces properly, wired goes down, etc, eventually something= gets killed off, usually the offending process but this is something else i don't fully get=2E as i use zfs, i blame it= =2E maybe i should not On April 22, 2025 6:49:43 PM GMT+03:00, Rick Macklem wrote: >I wouldn't normally top post, but all I have is a generic question=2E > >Do you have a swap partition setup? >(I'd use something like 6-8Gbytes for a 4Gbyte system=2E) > >rick > >On Tue, Apr 22, 2025 at 8:23=E2=80=AFAM Sulev-Madis Silber > wrote: >> >> well i don't have those errors anymore so there's nothing to give >> >> i've tried to tune arc but it didn't do anything so i took those things= off again >> >> right now i'm looking at >> >> ARC: 1487M Total, 1102M MFU, 128M MRU, 1544K Anon, 56M Header, 199M Oth= er >> 942M Compressed, 18G Uncompressed, 19=2E36:1 Ratio >> >> and wonder wtf >> >> i bet there's issue somewhere and i somehow can't properly recreate it= =2E on memory pressure it does resize arc down properly so seems like i don= 't need any limits >> >> and there's no tmpfs=2E it would be useless at that low memory sizes >> >> the problem is that i can't figure out what all those problems are, how= to recreate those conditions and how to workaround or maybe find bugs=2E a= lso don't have enough hw to solely test it on=2E unless i can maybe try it = on tiny 512m vm=2E and then i would need to know what to try >> >> i also don't know why those git settings help me: >> >> [core] >> packedGitWindowSize =3D 32m >> packedGitLimit =3D 128m >> preloadIndex =3D false >> [diff] >> renameLimit =3D 16384 >> >> how to tune it from some global place=2E and so on=2E and why it would = even need fiddiling so much? zfs indeed has improved a lot, previously it w= as quite a hell to use >> >> i don't even know if this is related to mmap=2E even then, i don't real= ly get what that function even does=2E hence then "zfs (?) issue"=2E it mig= ht even not be zfs at all >> >> there are probably multiple combined issues here >> >> i also don't really buy the idea that ton of ram would automatically fi= x this >> >> so yeah unsure what to think of this >> >> some of the issues i found that others also have=2E some of them seem n= ew >> >> some fixes were like as if trial and errors and nobody seemed to know w= hat's wrong even=2E granted, that was forum so maybe here it's better here? >> >> i mean i have used below average equipment my entire life and usual cas= e to cope with this is to just give it more time=2E put more swap and just = wait >> >> i think someone tested my git issues in 4g vm and found no issues at al= l? other things seem like as i only i have them >> >> i also find kind of confusing that if this is hw, why i don't see any o= ther issues >> >> this is not the first time that i have found something confusing in fbs= d that later turned out to be bug and was further tested and fixed by other >> >> hence the current mailing list so maybe someone else has ideas=2E or if= it has already fix=2E and i hope there are people with much larger labs an= d could easily tell / test things >> >> so in the end, >> >> 1) why should git on large repo cause machine to run out of memory, ins= tead of just being as slow as it would need to be >> >> 2) why / what are fs operations that could cause low power machine to m= ysteriously fail on zfs, when expected results would be slow fs behaviour >> >> i don't know what really happens and it's way too complex me to get all= memory management that happens in kernel=2E i only have this wild guess th= at any type of caching should happen in "leftover" ram and make things fast= er if possible=2E and any fs operations that have already reported complete= d by kernel can't be suddenly found incomplete later=2E whatever that fs-re= lated stray buildworld error was that resolved itself somehow=2E and what i= can recreate >> >> and i'm not expert in this so how do i even know? >> >> what's fun is how running rsync over several tb's of data doesn't seem = to cause any issues at all=2E this is still same machine, many would not re= commend using this=2E different workload? >> >> hell knows what's all this=2E maybe later i could figure it out or actu= ally save some logs or=2E those i didn't save as i assumed it repeats itsel= f=2E didn't and it went off tmux window history >> >> oh well=2E yes, this is questionable report but those are "heisenbugs" = as well=2E at least some? >> >> >> >> On April 22, 2025 3:52:11 PM GMT+03:00, Ronald Klop wrote: >> >Hi, >> > >> >First, instead of writing "it gives vague errors", it really helps oth= ers on this list if you can copy-paste the errors into your email=2E >> > >> >Second, as far as I can see FreeBSD 13=2E4 uses OpenZFS 2=2E1=2E14=2E = FreeBSD 14 uses OpenZFS 2=2E2=2EX which has bugfixes and improved tuning, a= lthough I cannot claim that will fix your issues=2E >> >What you can try is to limit the growth of the ARC=2E >> > >> >Set "sysctl vfs=2Ezfs=2Earc_max=3D1073741824" or add this to /etc/sysc= tl=2Econf to set the value at boot=2E >> > >> >This will limit the ARC to 1GB=2E I used similar settings on small mac= hines without really noticing a speed difference while usability increased= =2E You can play a bit with the value=2E Maybe 512MB will be even enough fo= r your use case=2E >> > >> >NB: sysctl vfs=2Ezfs=2Earc_max was renamed to vfs=2Ezfs=2Earc=2Emax wi= th arc_max as a legacy alias, but I don't know if that already happened in = 13=2E4=2E >> > >> >Another thing to check is the usage of tmpfs=2E If you don't restrict = the max size of a tmpfs filesystem it will compete for memory=2E Although t= his will also show an increase in swap usage=2E >> > >> >Regards, >> >Ronald=2E >> > >> > >> >Van: Sulev-Madis Silber >> >Datum: maandag, 21 april 2025 03:25 >> >Aan: freebsd-current >> >Onderwerp: zfs (?) issues? >> >> >> >> i have long running issue in my 13=2E4 box (amd64) >> >> >> >> others don't get it at all and only suggest adding more than 4g ram >> >> >> >> it manifests as some mmap or other problems i don't really get >> >> >> >> basically unrestricted git consumes all the memory=2E i had to turn = watchdog on because something a git pull on ports tree causes kernel to tak= e 100% of ram=2E it keeps killing userland off until it's just kernel runni= ng there happily=2E it never panics and killing off userland obviously make= s the problem disappear and nothing will do any fs operations anymore >> >> >> >> dovecot without tuning or with some tuning tended to do this too >> >> >> >> what is it? >> >> >> >> now i noticed another issue=2E if i happen to do too many src git pu= lls in a row, they never actually "pull" anything=2E and / or clean my obj = tree out=2E i can't run buildworld anymore=2E it gives vague errors >> >> >> >> if i wait a little before starting buildworld, it always works >> >> >> >> what could possibly happening here? the way the buildworld fails mea= ns there's serious issue with fs=2E and how could it be fixed with waiting?= it means that some fs operations are still going on in background >> >> >> >> i have no idea what's happening here=2E zfs doesn't report any issue= s=2E nor do storage=2E nothing was killed with out of memory but arc usage = somehow increased a lot=2E and it's compression ratio went weirdly high, li= ke ~22:1 or so >> >> >> >> i don't know if it's acceptable zfs behaviour if it runs low on memo= ry or not=2E how to test it=2E etc=2E and if this is fixed on 14, on stable= , or on current=2E i don't have enough hw to test it on all >> >> >> >> i have done other stuff on that box that might also improper for amo= ung of ram i have there but then it's just slow, nothing fails like this >> >> >> >> unsure how this could be fixed or tuned or something else=2E or why = does it behave like this=2E as opposed to usual low resource issues that ju= st mean you need more time >> >> >> >> i mean it would be easy to add huge amounts of ram but people could = also want to use zfs in slightly less powerful embedded systems where lack = of power is expected but weird fails maybe not >> >> >> >> so is this a bug? a feature? something fixed? something that can't b= e fixed? what could be acceptable ram size? 8g? 16g? and why can't it just = tune everything down and become slower as expected >> >> >> >> i tried to look up on any openzfs related bugs but zfs is huge and i= 'm not fs expert either >> >> >> >> i also don't know what happens while i wait=2E it doesn't show any s= erious io load=2E no cpu is taken=2E load is down=2E system is responsible >> >> >> >> it all feels like bug still >> >> >> >> i have wondered if this is second hand hw acting up but i checked an= d tested it as best as i could and why would it only bug out when i try mor= e complex things on zfs? >> >> >> >> i'm curious about using zfs on super low memory systems too, because= it offers certain features=2E maybe we could fix this if whole issue is ra= m=2E or if it's elsewhere, maybe that too >> >> >> >> i don't know what to think of this all=2E esp the last issue=2E i'm = not really alone here with earlier issues but unsure >> >> >> >> >> >> >> > >> > From nobody Wed Apr 23 03:11:19 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 4Zj3zQ6mBmz5sd54 for ; Wed, 23 Apr 2025 03:11:30 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4Zj3zN5HvHz3FqG for ; Wed, 23 Apr 2025 03:11:28 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=sJQuwqe3; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1745377885; bh=s6aJoCKZbfAXf5Ei0brd3yseq3kxz+HLe352zFq6x18=; h=Date:From:To:Subject:In-Reply-To:References; b=sJQuwqe3v0KlWxnLm9bFSkhWNUBqSacK9q6OJiGr9iYgQzJrw/qfYBTwpsNtMrcVl cdx+gTajf2g36tFYZsTrDpLrObaZUGVbP1bBkcuDcg2IuiL9AqJRUDlN4GzKlXgWmj eqlHovNtAaOjdaujqnpbXaX9g5JVCdg99P8EypTtVnh0W7HpzzrVTvbxgy2cxZCMj0 VVY/rTTmLgyxC6xNJyALYP9I9wRVedvR/2ZyXVk5xLITpXknbc51oeeNo/bsNdjpW0 2tnr4RytCtAPQ/wuAYatPLiMcs7cXUB3QaAfVaFmiOUSaOWJ2a6K7EayeOvovs6iZx 0puLEztuLjw/kUOq73OAgxnom15oQaQI2lAJ5ioShEN4kUO33KT8GaLmwgHkgoOCHs DcJSsm3XdTUygryMTptywiziwqmBy0YOnln+pksG6SyjqZ5vmnCd87a/YWIMjPN0Zk acY+VajwfPyUcOiXlw7Zy0Owo8RvMlaoYqvV8+fvmTGEEg3TXu/wGrtn/5/Ax6aARl B/daM5G5NtIsdf3IYUdg5VbVwkDwJIQdVZCjofi10z/nqKI/V5UFpKZelcpz7RyoW/ h7758JE2waEtNBVLFeoTyq0I2Hr+oaRvV4c7XX+PJADVeh/melJZ0Tqwd9TNAeZOdh kMZ5ba9d9bOAjmJBr/9r7Kbw= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 6B2945B37F1 for ; Wed, 23 Apr 2025 06:11:21 +0300 (EEST) Date: Wed, 23 Apr 2025 06:11:19 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: zfs (?) issues? User-Agent: K-9 Mail for Android In-Reply-To: <1A4907E8-315F-4A34-95F6-E6A184B9DCC8@me.com> References: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> <1357110019.7132.1745326331870@localhost> <1A4907E8-315F-4A34-95F6-E6A184B9DCC8@me.com> Message-ID: <1C84473E-8D20-4636-8CF7-9CD8240D58B0@ketas.si.pri.ee> 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-Spamd-Result: default: False [2.06 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.90)[-0.902]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_HAM_LONG(-0.24)[-0.236]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.00)[0.002]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4Zj3zN5HvHz3FqG X-Spamd-Bar: ++ On April 22, 2025 8:34:35 PM GMT+03:00, Toomas Soome wro= te: > > >> On 22=2E Apr 2025, at 18:23, Sulev-Madis Silber wrote: >>=20 >> well i don't have those errors anymore so there's nothing to give >>=20 >> i've tried to tune arc but it didn't do anything so i took those things= off again >>=20 >> right now i'm looking at >>=20 >> ARC: 1487M Total, 1102M MFU, 128M MRU, 1544K Anon, 56M Header, 199M Oth= er >> 942M Compressed, 18G Uncompressed, 19=2E36:1 Ratio >>=20 >> and wonder wtf >>=20 >> i bet there's issue somewhere and i somehow can't properly recreate it= =2E on memory pressure it does resize arc down properly so seems like i don= 't need any limits >>=20 >> and there's no tmpfs=2E it would be useless at that low memory sizes >>=20 >> the problem is that i can't figure out what all those problems are, how= to recreate those conditions and how to workaround or maybe find bugs=2E a= lso don't have enough hw to solely test it on=2E unless i can maybe try it = on tiny 512m vm=2E and then i would need to know what to try >>=20 >> i also don't know why those git settings help me: >>=20 >> [core] >> packedGitWindowSize =3D 32m >> packedGitLimit =3D 128m >> preloadIndex =3D false >> [diff] >> renameLimit =3D 16384 >>=20 >> how to tune it from some global place=2E and so on=2E and why it would = even need fiddiling so much? zfs indeed has improved a lot, previously it w= as quite a hell to use >>=20 >> i don't even know if this is related to mmap=2E even then, i don't real= ly get what that function even does=2E hence then "zfs (?) issue"=2E it mig= ht even not be zfs at all >>=20 >> there are probably multiple combined issues here >>=20 >> i also don't really buy the idea that ton of ram would automatically fi= x this >>=20 >> so yeah unsure what to think of this >>=20 >> some of the issues i found that others also have=2E some of them seem n= ew >>=20 >> some fixes were like as if trial and errors and nobody seemed to know w= hat's wrong even=2E granted, that was forum so maybe here it's better here? >>=20 >> i mean i have used below average equipment my entire life and usual cas= e to cope with this is to just give it more time=2E put more swap and just = wait >>=20 >> i think someone tested my git issues in 4g vm and found no issues at al= l? other things seem like as i only i have them >>=20 >> i also find kind of confusing that if this is hw, why i don't see any o= ther issues >>=20 >> this is not the first time that i have found something confusing in fbs= d that later turned out to be bug and was further tested and fixed by other >>=20 >> hence the current mailing list so maybe someone else has ideas=2E or if= it has already fix=2E and i hope there are people with much larger labs an= d could easily tell / test things >>=20 >> so in the end, >>=20 >> 1) why should git on large repo cause machine to run out of memory, ins= tead of just being as slow as it would need to be > > >um, because it is buggy? Or pick some other fun reason, because the this = wording does not really make much sense=2E how to "un"bug it? why is it allowed to trash system? i'm not expecting gi= t run to cause git, sshd, getty, syslog, etc to die=2E i don't think anyone= wants it=2E no swapping, system down in few seconds=2E sadly it's hard to = repeat as it needs large repo and ton of things to update=2E could it give = some clues? some say git is bad too=2E maybe=2E first vcs with sane ui for = me=2E i'm up for better tools > > >>=20 >> 2) why / what are fs operations that could cause low power machine to m= ysteriously fail on zfs, when expected results would be slow fs behaviour >>=20 > >define low power? in general, the failures on system with limited resourc= es hint about lack of testing and bug hunting in such systems=2E Over time,= there have been improvements, but this is almost never ending task=2E like c2d 4g=2E i'm sure we find embedded equivalent here too=2E since most= of my zfs tasks don't surprise me with outcome=2E only a few=2E how to mak= e all of them be unsurprising? > > >> i don't know what really happens and it's way too complex me to get all= memory management that happens in kernel=2E i only have this wild guess th= at any type of caching should happen in "leftover" ram and make things fast= er if possible=2E and any fs operations that have already reported complete= d by kernel can't be suddenly found incomplete later=2E whatever that fs-re= lated stray buildworld error was that resolved itself somehow=2E and what i= can recreate >>=20 > >default fs operations are asynchronous, if you want them to be =E2=80=9Cc= omplete=E2=80=9D, that is, data on stable storage and consistent state for = file system, you need synchronous IO=2E But as always, there is price to pa= y=2E yeah=2E i know=2E but here i'm afraid i was able to trash some of it with = my actions=2E the buildworld logs that i failed to capture were about unabl= e to create or find some files=2E or open=2E or=2E=2E=2E i was wtf=2E they = never reappeared=2E ran again, no, errors=2E same tree=2E at fs, no checksu= m errors, scrubs are fine, etc > > >> and i'm not expert in this so how do i even know? >>=20 >> what's fun is how running rsync over several tb's of data doesn't seem = to cause any issues at all=2E this is still same machine, many would not re= commend using this=2E different workload? >>=20 > >If you are comparing git with rsync, you want to make sure you have up to= date git=2E There are git versions with rather nasty bugs=2E latest git > > >> hell knows what's all this=2E maybe later i could figure it out or actu= ally save some logs or=2E those i didn't save as i assumed it repeats itsel= f=2E didn't and it went off tmux window history >>=20 >> oh well=2E yes, this is questionable report but those are "heisenbugs" = as well=2E at least some? >>=20 > > >Heisenbug is bug for which we do not yet know the trigger mechanism, it d= oes not mean they do not have such mechanism=2E i have no idea how to test=2E maybe it's disk io speed=2E maybe cpu speed= =2E maybe ram size=2E i didn't write git, fbsd kernel or (open)zfs=2E didn'= t build the machine's hardware either=2E but i managed to break one or more= of them=2E i have broken things before=2E call me good tester then=2E some= have ended up being actual bugs=2E found by "why would anybody ever do thi= s"=2E note that git trashing the fbsd when zfs is used is not only found by= me=2E but others seemed as smart as me which was not helping=2E what is, i= 'm unsure=2E i can't even explain what i do apparently=2E so i guess it's u= p to me to test it in the end=2E this could mean running actual hw with dif= ferent setups=2E or maybe if could be emulated=2E but it could also emulate= bugs away=2E what if this someone's 4g test vm was on top notch hw with nv= me storage and therefore was super fast io, so fs operations immediately co= mplete even in their async form, never hogging system up? that would mean b= ug is left in too=2E it only appears in some cases=2E it's wild guess too= =2E it might be legit bug, only surfacing on some cases=2E only to maybe su= rface later=2E imagine your vm host is experiencing resource exhaustion, ca= using guests to behave exactly like old actual hw, letting bug appear anyway i was hoping i could find more knowledge and hw here i also wondered if this is just my hw=2E but at least with 1 of 2 issues, = someone else also reported having that problem so yeah, hard to figure this all out so far i tried arc limits=2E it went past that=2E is there a known way for= zfs to take memory outside of arc? like all memory, fast? tests done by others confirmed that ufs =3D ok, zfs =3D fail any git pull+rm obj+make buildworld, for that i can't find any=2E i even t= ried to look for fixed openzfs bugs, related or unrelated to it being on fb= sd host=2E it's massive beast=2E without fs dev exp, i could find any reall= y since it all seems to revolve around git=2E any ideas? even if it's buggy,= if it brings other bugs out, it's good, no? it wasn't git what failed=2E i= t seems like git causes zfs to consume huge ton of memory=2E i even ran fs = test tools=2E hoping to cause a failure again=2E and memory=2E i read my gi= t config affects mmap=2E which, in my knowledge is not a method to consume = all actual memory as in ram, but rather map files to memory somehow=2E i tr= ied to run those tests as well=2E couldn't get it to fail=2E don't know wha= t it is right now i don't have test-to-destruction equipment here so i'm looking s= ome nondestructive methods=2E or at least confirm it's an old, fixed, bug so no idea what to think of all this=2E it's all also kind of stock=2E lik= e i don't have my own changes to any of this=2E only blame would be to run = old hw=2E if that's even the issue=2E i have looked into many other tuning = options as well, didn't help or didn't find any=2E so i don't have methods = to test, find a tunable or bug i would guess i would drop it again for a year or more and come back later= =2E maybe when i have 14 either on this machine or any other machine=2E or = current or unsure, maybe it's only me that found this=2E but then=2E not really? tl;dr - i seem to have certain unusual zfs issues on low ram box i can't p= ut my finger to, despite putting effort into it > >rgds, >toomas > >>=20 >>=20 >> On April 22, 2025 3:52:11 PM GMT+03:00, Ronald Klop wrote: >>> Hi, >>>=20 >>> First, instead of writing "it gives vague errors", it really helps oth= ers on this list if you can copy-paste the errors into your email=2E >>>=20 >>> Second, as far as I can see FreeBSD 13=2E4 uses OpenZFS 2=2E1=2E14=2E = FreeBSD 14 uses OpenZFS 2=2E2=2EX which has bugfixes and improved tuning, a= lthough I cannot claim that will fix your issues=2E >>> What you can try is to limit the growth of the ARC=2E >>>=20 >>> Set "sysctl vfs=2Ezfs=2Earc_max=3D1073741824" or add this to /etc/sysc= tl=2Econf to set the value at boot=2E >>>=20 >>> This will limit the ARC to 1GB=2E I used similar settings on small mac= hines without really noticing a speed difference while usability increased= =2E You can play a bit with the value=2E Maybe 512MB will be even enough fo= r your use case=2E >>>=20 >>> NB: sysctl vfs=2Ezfs=2Earc_max was renamed to vfs=2Ezfs=2Earc=2Emax wi= th arc_max as a legacy alias, but I don't know if that already happened in = 13=2E4=2E >>>=20 >>> Another thing to check is the usage of tmpfs=2E If you don't restrict = the max size of a tmpfs filesystem it will compete for memory=2E Although t= his will also show an increase in swap usage=2E >>>=20 >>> Regards, >>> Ronald=2E >>>=20 >>>=20 >>> Van: Sulev-Madis Silber >>> Datum: maandag, 21 april 2025 03:25 >>> Aan: freebsd-current >>> Onderwerp: zfs (?) issues? >>>>=20 >>>> i have long running issue in my 13=2E4 box (amd64) >>>>=20 >>>> others don't get it at all and only suggest adding more than 4g ram >>>>=20 >>>> it manifests as some mmap or other problems i don't really get >>>>=20 >>>> basically unrestricted git consumes all the memory=2E i had to turn w= atchdog on because something a git pull on ports tree causes kernel to take= 100% of ram=2E it keeps killing userland off until it's just kernel runnin= g there happily=2E it never panics and killing off userland obviously makes= the problem disappear and nothing will do any fs operations anymore >>>>=20 >>>> dovecot without tuning or with some tuning tended to do this too >>>>=20 >>>> what is it? >>>>=20 >>>> now i noticed another issue=2E if i happen to do too many src git pul= ls in a row, they never actually "pull" anything=2E and / or clean my obj t= ree out=2E i can't run buildworld anymore=2E it gives vague errors >>>>=20 >>>> if i wait a little before starting buildworld, it always works >>>>=20 >>>> what could possibly happening here? the way the buildworld fails mean= s there's serious issue with fs=2E and how could it be fixed with waiting? = it means that some fs operations are still going on in background >>>>=20 >>>> i have no idea what's happening here=2E zfs doesn't report any issues= =2E nor do storage=2E nothing was killed with out of memory but arc usage s= omehow increased a lot=2E and it's compression ratio went weirdly high, lik= e ~22:1 or so >>>>=20 >>>> i don't know if it's acceptable zfs behaviour if it runs low on memor= y or not=2E how to test it=2E etc=2E and if this is fixed on 14, on stable,= or on current=2E i don't have enough hw to test it on all >>>>=20 >>>> i have done other stuff on that box that might also improper for amou= ng of ram i have there but then it's just slow, nothing fails like this >>>>=20 >>>> unsure how this could be fixed or tuned or something else=2E or why d= oes it behave like this=2E as opposed to usual low resource issues that jus= t mean you need more time >>>>=20 >>>> i mean it would be easy to add huge amounts of ram but people could a= lso want to use zfs in slightly less powerful embedded systems where lack o= f power is expected but weird fails maybe not >>>>=20 >>>> so is this a bug? a feature? something fixed? something that can't be= fixed? what could be acceptable ram size? 8g? 16g? and why can't it just t= une everything down and become slower as expected >>>>=20 >>>> i tried to look up on any openzfs related bugs but zfs is huge and i'= m not fs expert either >>>>=20 >>>> i also don't know what happens while i wait=2E it doesn't show any se= rious io load=2E no cpu is taken=2E load is down=2E system is responsible >>>>=20 >>>> it all feels like bug still >>>>=20 >>>> i have wondered if this is second hand hw acting up but i checked and= tested it as best as i could and why would it only bug out when i try more= complex things on zfs? >>>>=20 >>>> i'm curious about using zfs on super low memory systems too, because = it offers certain features=2E maybe we could fix this if whole issue is ram= =2E or if it's elsewhere, maybe that too >>>>=20 >>>> i don't know what to think of this all=2E esp the last issue=2E i'm n= ot really alone here with earlier issues but unsure >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 > > From nobody Wed Apr 23 03: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 4Zj4L20CGkz5sddN for ; Wed, 23 Apr 2025 03:27:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zj4L03Qn3z3HH8 for ; Wed, 23 Apr 2025 03:27:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=I3Ni9DFN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745378854; bh=YZ/RL+sVGkGcwV3sIvw/HZInOP+ECLA52lpMnsHt8D4=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=I3Ni9DFNQOYnbnAGH4Kij65eV2HVtI3am/JHOl4oDWA5D5wVxWeOnJdXQWPQwBu8m5+F2pOqBTbmxr9oTdB975cMnhIfWdYuZ8iUq5FaMbMjfpbbTrDVIBPsnk/iMdDzYs7reC/2o/MlLQtnZSmbkqurCEZWSlbLzKPPR09sPXMLZoN7E99n/mcHc2HOE6og3f66ny0S0uY1nqCk6xFlV04s8crDei6ZHyoySfudq+DYupKDJ131xZMWYTyXW9C66qIQdAw4xN3trcvM9Dg8UsYZJagJRsL4XGFhvHikFqk8oBdWstu+ASqCJpz8BFFBokMVSeP+0VtPNwH6OkB6Vg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745378854; bh=Zn0lcTsVCBOLGTtu/k9fRoTM8i+77utQYUTWHF1isJX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=XejX2wl4/Hv8bFF1UBBmwZ3hP3qFKUBoK6+eH3Q+0dBjIqwVq9+VLWrV8yDcQNptIIKJLWb0EtMK6vnbrhAmh/tZg13vbnT4Tpyu6l2iCIliQVuEPONK/Mc6z86nr7RZlKMuNiCHEbsGdenBsRoMwv9THXQI1HUgvH9PKXBsHrvfdajvhwgyYsHvaVCiwv6OAT0mXNjc3B8EAZf8xywaf06gRYzWrMY4jUw+jAdQjNngZtrBtaxQJhOAN0ovEU30Glhf6DMzZNaXl4t6ov4eJrf2woc99TC1PGokJFKLJRrtsrh77DwcUpO+QrvC45Z8X0/w46B2j48o5rZ7evKVtg== X-YMail-OSG: FFbfzWEVM1l5WToa_BkKc7t7EzwSocrmm6AQOR0KEgvtw_C3e4hVnlE5eFkIAnE 0fE580_wRWPfcyD.rKYhsleB5fbk9HaHknT23fz9856Z67Z93d.5CVog7Jgu9wLh_JdMkj8S8r73 CS7DJvYf4T1A00NVLxCnU0PSUtx8N5f2Sq4Qs2FOkavxZw.TLbVECycxf3LSnUCU.dmWjnesu7KT DAkL3Bz8WWC5HYaHh4u1PMT5FnPgakE2c8k5QSGN6r7F7VnEF24fHkk0.eI2nAME6UyDeWUIIbhX t9vQZZY53Og6caENZQbL170R5LftW.fXXW6fFZmoRfe9GzDdop5ddP3sUjCJgPVATGPmd7tKjM7y .q9zMtEV9cyLc3O3YjXyL89.Gq5Z_EU72k9eMaqR8kcxQyllAbo2vmKeSatu6ThE7LX.ykJH1yZG jrhLw88Xm3SQ_.hpkGVbwePYVN3AGbN_DB1nU1tmTde3njW19QUTcWGTd8CsUWXw1s0e426.B_ft 5Z6GSXz0W15sRMixIM_5lcwE1xWVwEmE5ZTQ_2iblLkW4SlItlKiQSHEnbbbLwg20EMta9gUSA6Z y2Y3JJLwW32qsSZu7VhVQxYFxWyDsZSXV0I1.Aq2FlLPvtCst5HpO1URm5beCVHIN5y3DjfmNhPs 6SWmpkdcjQSenrk6bj8YclZfo4PSNWX6QK1Sdofv_DiBsKXnAwHsYZffOdvh9tj7KYYXkvFStFcG f4oAIxj88MeV_r4wP9i2lwYZpDMJZvAmnjOA4EfGHKNOygfXn5NSLipbtoatPX6_oVt0gQF8wWDw T8cxGfBp3Mj.rPlzOAy_jOYIRii1G9_.H.DzYb_MHMM5WDvLHrnaXQzL0Jm70DRSFdICvps3XULe h4KleAiE58W5hmFbdDN32yxgTA9t6ODK1mJfXeBe55Eszzk49t_IiJXNL30LHcWYtb8MR7b9Fzj4 mb3l_XtKy5Bi5PyEC6rlOGKR0AbdbhB1pLXceE5fApDlYZI9AJWRti1pvI4Gvi_FenHrYLK3BN88 fC7ow2p4C5dEPaSXGLgbE5LFXhptHOPxd5OWEstVWVPvKPJ6Upk78quzry3tXObAqtZIs3TqfhDy ouYxFWDpq6xwPdrriiabVJ_Lx0qLu.BMnb0A_PS7FNZHcp2ajN0g8EH67w0NlarC_7hqfvFJIOl1 J3vuj5N.F5YpPtlNzKbXcA6.0Nu_idtuvvGKZGKGECNuAoqobR4cHGaBW7B1kAUUROKOjcxfSgzs vF.Vh4kLh.LpMaxoutomjTxs2GuyIxu.NPBkqVbikyr7QumSbqf9RQeStC3CUAN3OhVS9DFxHyKV .CI94s2WceetGH1BuDD6CDT4ZtGf14pOwkF0Ov_zI_a_mB92wP_fRrWHruOPc5gtxPdwgfwa_irj 2HpB8Rtksaeb4od_QM4Z5REAScazC5WQkOiWV0NQWRKyXFBfAxcRKWbyiRB_1TDeUHaHkxAJ.02R lHr1DBajUjDvQWXFOtka4mDJw5thufKaWMV37Sy1yYLyZPcrDkpAWG2KIVA11.CXSom0okvcVFOL OBR6jo_7fDKfkkvCJEO5T_WF6zNsONQabqwI_Jd4SGk0MBv5lsCwAuq3kS2a6DBWS2pEvYOr2FBw VYQEnh4DIl.bWP44imj7H7uO.ClAcK7i0FV4ddLPJpO1tD8G4NlBlSOnalATjIxlC4lEOrbteNC8 3Ugfbtce4Ue_3KbIYxnTFuWdh9bOmvstf4AQNe6u9SFNojwLqGBJbDChzNbIziKz_iZAaF2zqtbt eW0wwchguXZPG0HyxVxW0pMfOu20JEZ0hjfQWA.VeNUkjrl5wuvo4UNYUcrSsPl2vZ9A1yE6X9NK roKUeazYA4ieNRfRLYoskP6ZAT9Lg0RJoRSMGCHFKuJQK698zuL.SfvNy5pUL3eJCfIpkBjgNrIf c4Xc2mlw.9fuTLq2yTn7YGjjHu5oTta6R2JADgTECwoJZ6BIxNM7fTDipevzK36amHV4vTOd8aij dNKU1TnCSu.vyXhuLvVz9QnrYUeNdpK3EVS41pH7GZbe66u4RQAhQNqMCR0rWYIpLX_9MEKO06Xe AK0f5MnKQhgcl.cdrmESOsFd2SUZB3frRUQKtLSlqu7_Pg1xHHxPoc21ijsp2dj8eNyCbHND2K1L FhwguNKhH5xY4g_H7mi61NOo9RObFimWIbDgllaXqS15Y9k1qutM4dEMoBQPi21ymPXIarJ22APS Tjocombx9qTr4Y7NTx4udVWqQe3Yv6g5Zka4Sbgxaiz4kNYgaswmLzoqbpuMxN3Jg0F4gA79y6k0 - X-Sonic-MF: X-Sonic-ID: 97ac6d0b-3e79-452d-8e77-6071563ced4c Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Apr 2025 03:27:34 +0000 Received: by hermes--production-gq1-74d64bb7d7-45lk9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ea9c1d5768d3c103d6ceb18d886b221d; Wed, 23 Apr 2025 03:27:31 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: zfs (?) issues? Message-Id: <61B5E2C7-EEF9-4DD8-8BB3-77B530FE1565@yahoo.com> Date: Tue, 22 Apr 2025 20:27:20 -0700 To: freebsd-current-freebsd-org111@ketas.si.pri.ee, FreeBSD Current X-Mailer: Apple Mail (2.3826.500.181.1.5) References: <61B5E2C7-EEF9-4DD8-8BB3-77B530FE1565.ref@yahoo.com> X-Spamd-Result: default: False [-2.47 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.148:from]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.991]; NEURAL_HAM_MEDIUM(-0.78)[-0.778]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.20)[-0.204]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4Zj4L03Qn3z3HH8 X-Spamd-Bar: -- Sulev-Madis Silber = wrote on Date: Wed, 23 Apr 2025 02:04:28 UTC : > yes, 2 * 8g partitions on separate disks, so i have 16g swap >=20 > . . . >=20 > >> >Van: Sulev-Madis Silber = > >> >Datum: maandag, 21 april 2025 03:25 > >> >. . . > >> >> > >> >> others don't get it at all and only suggest adding more than 4g = ram >=20 > . . . I have no clue if this will be of any help. For 64-bit systems, having total SWAP much greater than, say, 3.6*RAM normally produces a warning about potentially being in a mistuned state. They look like, for example: warning: total configured swap (477183 pages) exceeds maximum = recommended amount (466816 pages). warning: increase kern.maxswzone or reduce amount of swap. If I understand right, adjusting kern.maxswzone makes other tradeoffs that I do not know the details of. Thus I avoid getting the messages by adjusting the SWAP space size instead. I've been told that the messages suggest a higher likelihood of deadlocks happening while managing the memory space.(Others may known what they are doing with kern.maxswzone adjustments and could judge the tradeoffs.) Are you getting such messages on your console or that you can see from "dmesg -a" or in /var/log/messages ? (The detailed multiplier changes some from system update to system update. I can not report a fixed multiplier. I leave margin to make it unlikely that I'd get the notice across various updates.) 3.6 * 4 GiBytes =3D=3D 14.4 GiBytes SWAP, as an example. Then RAM+SWAP =3D=3D 4.6*RAM, so 18.4 GiBytes or so as a memory space. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 23 04:29:43 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zj5k210flz5sht1 for ; Wed, 23 Apr 2025 04:30:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zj5jz5Jhdz3Rpr for ; Wed, 23 Apr 2025 04:29:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=P6yIYZHo; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745382597; bh=Oj3sWbnFIIRp5h3fBdMX5bWZ5ZBtPXjI6KtW/hhKT1Q=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=P6yIYZHoPvvssqQgBB1GbaOXJWcVTlw/7M+nLf/t6lvq+Qdqz5UBjyzTcBnzZRiqb6Qc3iZejSpGt1Nxxs97JIjeUy8I37nFIGL/Q9aaL//tihj01mjS2JNsDNb02CdoxRFVqyvVw2W7LOe4ke7ko5dnYxqhuu98EXJc07mlzihjCEjTn7Jffqjc2SCGX0IijSsxaky+N9+0Tct/paeoVLPZ+BN0bVUvSvUBMG9TQSmQiGlqXjTjKXyWg3tcGL7Gq0UKz8+BGRAYoYtu2QtZ0hl9C/DsmHPApj8OM4K+WCr9IBL3JED8uT1osZpXHIeqw922IKrOGQ7jqSJCIXutjw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745382597; bh=Fn9b3XX0rbzLMhoKSKy1cDjE78Kop540v1XWuhrv/G9=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Lyt3DTW4PWzGcaSGcY8yyg3CDkWLLdnmTNDksh8Z5/AcmQfF4se0pBvoVuHb7R87Ptu1OEHYE7143YYAuy9PscRBczfrELTceeNfSIVB4GjLYgWmyXhCShDua3xlmrcGv4hYIdbm8Jv3a+sCH7T6n90JExAjcqt0yWnS0g9jRNNlzmDmiYiHALnUFvGUMA2CN5DcQT7P0dajA3ONWvpC3NIRon2OGJzoBYr2R5l/PoFXDaslb0TjkPlH1fxbqy4y38wkSQMvs0ZTuKGof7FBlgHvk0IQ7jj3j9LjDl0tfJyAV16A1ePtR9//Swluu4rB8xcxb9prQ7Ak70E9Rlw1+A== X-YMail-OSG: vNx5uBYVM1lQxgy8vrsMW2XUV8xnqM47RuAZUdoG4Od3McMA02JimpjbpehHUq4 WC7YMcfcfUQkfqFyYe34NKZOu_hhIBPiRqnJZbf4xAYr.GghKY1C5bGr4Ee92gGUwYSt1vItNmJp 5lgA80LqNCOX98uC4E_pyVYoeMddizFqTZJXCkS_dcC0QTWa2I9e54NRWHZLyG5fP0aVBTfb2iVn noW4VcxpD7wbO6JTfkNS0uVIIaBzOsg_8C_ngEcW1_Jg96BHBxibG4qOKpPe9n9gBwtrCh.YuTYy ZlZWT328gU3mc9Z6AWgL382kE5mgLq1Mim3NljUY5QO_CIosoHUaAHvPNrkSGAVJXlGK_Zcnf.eg ipzMEPh29Y7ySoVJx_PUi2EPFexRYJxje56sQ6Z8CpnWTYjoXKPfqAMln9n3soX1W5zYZtKPjoBR YkDN1RbQHNbgW344vpX6kqMBHFDsBCiC8AlSdxTOkPxeLXb05.a2M.NnYqmkM_lBZBBaJtLAD09X t6se51ojOdh9idWcCIbSIBpycpE2ios1Cm5UfotcEKc1XzkXuxuD.DxgHPwU9YWQzxmXnvRABYHk 4GuTiHcmsPcgedgcpu2k4VE0tMF0mgpnAC3l._mIa7SAK4mp_aGxDj46XS9OtJmbZGPOT3Zow04t EGcoLHWlQ0C2l2zdTtm140ucMqFvUBb8seL3SrmzHbn7sU3d.6x03v.AUBd.QVTzvVbjyeyXeMqx F_f7wsiu1il7ar1xl2tvo3LX14qJL8Tr7zj3VSdiDoe8ubY8JboapsbRK_77RxC6TcibklZst2xp nq_pDYoM9hadDysyUbukXMsrO4mKJNITsnQlQWlNzR0MDf.46Vp.0ffXsDTOKGyd6qv7iCE4RbhQ DCOkYGsMF0ZNG0CRF7G9nkFM0WJ06SIfOFhznZNA00K58JG79D1dXJ.9fHbwF4hDORsC1l2qnRGZ lb1ApP512Ts6UbStDjI1Xkl4H07Xj4eWvMl0U3mbhhhNECF6Sc6vwH_l1emwoZHI9aUXo2VeEAJ3 gZO7dtp_JMwfFycJU9UF53msmOTBhOp9HcjSfokxxTCRFaGzAReimyc5RRgTPEEYwT_erSlHCpL8 5d1EMfV_StslJ4vacbbJwUeUISgfopU1RoSgivJN.vlz4K2FRmAP_is1hbqpgObTUqAiLjPxn20p a9N8LBhZeQyGl06GjB12fs.MEIqlqcWku41hGmVyJs4btBGqJkCCuH61JHd1uqLHmjAugIw7lzxN DqXm6YPJEaslZm61DLJkIo1ClRYmxdTXEuRSiom2U9R18qvoHguvPe0MEkYF301QABrdxhJ20cWf Djnebg1HjxnSYmMBVI9y3Iop5D1c2N0vPmlFhv3j76Ib2GiEeOqbr.iHaDyDbf.qSW.QLEHWDzOn 6JHBZfImTogeQhnsFzm_g6O0Fqn_DPPfZe6BDQrZDDv6DkvGyNkmr9CuduZ6G7GPN8EC2WaP.HFv rIvY6KtcBW0q4puQP1QJrgYSPEXNG2nziOWRtC57buqRL76ZbZ7_kS7fPFbDR8V5Ql9PIHLlyFFY dxCkKv.sVa1yR6HgyS0Y_ZklwSEQ.urQ4LBqY9J2pot6yrgxOddik6Ul00q7XPEtXDgOz1KOcD54 w9e89a8BGTZRRY82Chg06C84rrNe6jaAcAJqDDSrLeBmE5fkioMkwt2eqW4H_Yanvs4tIGbMCvfm .2.MygXSeyp76gy8SDeN2u3vdmnRG6MbDmMAGUgvywD6ayisztPnHqWUCNdLc4pEWxrlwUKt3mkA mfMkSnPzt5tI337acryhoVC35WPNQltoVBLsYeXJ.DwHkVPUBc8r8e4wlNJkuktXkC6bxuEDL.7t dkzixacp0anyZVEGQCvSTrj8_8OAMxR93bAZ8JhNwosSKtgkF4ZrD3yz5hmE3OmeQhgryzCtxwsW PDT.zbn569L4uccLtEjEKx2TWeG_a3UVyUj7FyiBR3eQ8Gm0uHVELSrSeNgMm8TkNQe8BJavlVbh sH12HjLnlhnBzRr1FzkS7Kb9i2MxmDxFkNYly_4uEChfGuh2Zs8VxrTmgC70YgPdYcYGnVP9UhyX oSdbRrTCDgMIB.Da4sVD4ZvkaOJIMOIu4DQBUA0AyZl7At6NuufUyK7qfZCmSoYgo0hYUbP.fqL1 crhLQxXW4RWPUstU3V0jZOZg2iR5YW92qE4A50PXPkHUDhVnXcYkb3KpQ9z9Rcz8IO9RE7zMfVrY 7RroysSKqqH8q4g7yCoy7gEGNmTDL_afPLoSdP9bhGnxOXciCdCnQAcR1eDPZNjbBksWbc5sA9lH C X-Sonic-MF: X-Sonic-ID: be4ea818-2a43-4aa7-972f-0429a9191a92 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Apr 2025 04:29:57 +0000 Received: by hermes--production-gq1-74d64bb7d7-fddgg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0a31bfcaa7789930ac1fcdb7ff94d25c; Wed, 23 Apr 2025 04:29:53 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: zfs (?) issues? Date: Tue, 22 Apr 2025 21:29:43 -0700 References: <61B5E2C7-EEF9-4DD8-8BB3-77B530FE1565@yahoo.com> To: freebsd-current-freebsd-org111@ketas.si.pri.ee, FreeBSD Current In-Reply-To: <61B5E2C7-EEF9-4DD8-8BB3-77B530FE1565@yahoo.com> Message-Id: <2CD25DE4-2F94-4D00-A39B-1A1F24C263C0@yahoo.com> X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-2.67 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.65.206:from]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.954]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_LONG(-0.22)[-0.216]; 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)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from] X-Rspamd-Queue-Id: 4Zj5jz5Jhdz3Rpr X-Spamd-Bar: -- On Apr 22, 2025, at 20:27, Mark Millard wrote: > Sulev-Madis Silber = wrote on > Date: Wed, 23 Apr 2025 02:04:28 UTC : >=20 >> yes, 2 * 8g partitions on separate disks, so i have 16g swap >>=20 >> . . . >>=20 >>>>> Van: Sulev-Madis Silber = >>>>> Datum: maandag, 21 april 2025 03:25 >>>>> . . . >>>>>>=20 >>>>>> others don't get it at all and only suggest adding more than 4g = ram >>=20 >> . . . >=20 > I have no clue if this will be of any help. >=20 > For 64-bit systems, having total SWAP much greater than, > say, 3.6*RAM normally produces a warning about potentially > being in a mistuned state. They look like, for example: >=20 > warning: total configured swap (477183 pages) exceeds maximum = recommended amount (466816 pages). > warning: increase kern.maxswzone or reduce amount of swap. >=20 > If I understand right, adjusting kern.maxswzone makes other > tradeoffs that I do not know the details of. Thus I avoid > getting the messages by adjusting the SWAP space size > instead. I've been told that the messages suggest a higher > likelihood of deadlocks happening while managing the memory > space.(Others may known what they are doing with > kern.maxswzone adjustments and could judge the tradeoffs.) >=20 > Are you getting such messages on your console or > that you can see from "dmesg -a" or in > /var/log/messages ? >=20 > (The detailed multiplier changes some from system > update to system update. I can not report a fixed > multiplier. I leave margin to make it unlikely that > I'd get the notice across various updates.) >=20 > 3.6 * 4 GiBytes =3D=3D 14.4 GiBytes SWAP, as an example. > Then RAM+SWAP =3D=3D 4.6*RAM, so 18.4 GiBytes or so as a > memory space. Going in a different direction . . . Are you going to publish step-by-step instructions that repeat the problem(s) that you get in your context --with notes at/about the failure points? Also, you wrote . . . QUOTE i mean it would be easy to add huge amounts of ram but people could also want to use zfs in slightly less powerful embedded systems where lack of power is expected but weird fails maybe not END QUOTE The Design and Implementation of the FreeBSD Operating System (2nd edition) book says: QUOTE (Page 49, last paragraph) ZFS was designed to easily manage and operate enormous file systems, which it does well. Its design assumed that it would have many fast 64-bit CPUs with large amounts of memory to support these enormous file systems. When these resources are available, it works extremely well. However, it is neither designed for nor is it well suited to run on resource-constrained systems using 32-bit CPUs with less than 8 Gbytes of memory and one small, nearly full disk typical of many embedded systems. Thus, the fast filesystem continues to be the file system of choice for these smaller systems. END QUOTE NOTE: In my interpretation, the "32-bit CPUs" vs. "less than 8 Gbytes of memory" context referenced is that there is a problem if either issue is involved: CPUs can not substitute for needing sufficient RAM and RAM can not substitute for needing appropriate CPUs. QUOTING MORE (Page 548, 2nd bullet) Like all non-overwriting file sydstems, ZFS operates best when at least a quarter of its disk pool is free. Write throughput becomes poor when the pool gets too full. By contrast, UFS can run well to 95 percent full and acceptably to 99 percent full. END QUOTE I'll not quote about the mmap details that is one of the things that "works less well than UFS". (4th bullet.) I've no clue if you have a ZFS-based problem, but if you do it would not be surprising. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 23 04:31:41 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zj5m927Nxz5sjMm for ; Wed, 23 Apr 2025 04:31:53 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4Zj5m73sQWz3TMF for ; Wed, 23 Apr 2025 04:31:51 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b="O/4fuRoo"; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1745382702; bh=WwVhAsPnlF4lwxhA0tFD4PoWZx28mVVSLADjDjmmQKU=; h=Date:From:To:Subject:In-Reply-To:References; b=O/4fuRooMoq7mi8QqUCo+9g/YocZYpcccoTGyn42C+C3w7H7RNRF3ojESjsnfi6uu FfYf6l3XrjUkbJLQNi54dnbAkghn3OSKeTblnf61zH0WvkvrCQD8SOsWrf5jSvfCXb maTy1G5hSjMkfffSDb8QiVvyQnOwmh/8MuQIasALzTlar2fO9MqRx0gALwaFKVrWW1 lTPeN2G3Xw44GPehDIAlGy/5EunOcyskucSBR0HdipuY1RpzA37n0F7g/k/2xnl1Xc xiAbmtDb/H+5s+v8sPkAkQTE6kMT3TPm7g1RanE2w5WR1xlXJlSD5TqidE1vLYPTXc eXy8yj1uFI55QsEVKwVbNgOcE4jigRUXWqEMmy60nM/NUdsKjgt9gEczIqyh38ULt2 W7viPCM5oyl0VeXKKvnUYxDSLjlpCsZu9SWf3MG/1f/ndvU9eW6SbgusHg2Qyd2Miv nU0AvW2+BPYGUjYH4oZBSgsy4wC2ZzTe43MDP9t9j6I2Ln8IS/M+GxQ8FqnxaoTE+e tS7a3+LuEkzRgIYZlZ1G6W2i/7MWK8PahG7YmekaYkaI9l2vtwu/+q8GRvfKIawpqN 7ewnH3qHh2d4MKlUmGvvqHNScORiB3hrQiWhLgsa0QzUUSQO9hQkSO3AtqUiFNNeG+ xXkPvMOnBDp3S9kJMIVxqv9k= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 9A8455B3C9C for ; Wed, 23 Apr 2025 07:31:42 +0300 (EEST) Date: Wed, 23 Apr 2025 07:31:41 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: zfs (?) issues? User-Agent: K-9 Mail for Android In-Reply-To: <61B5E2C7-EEF9-4DD8-8BB3-77B530FE1565@yahoo.com> References: <61B5E2C7-EEF9-4DD8-8BB3-77B530FE1565.ref@yahoo.com> <61B5E2C7-EEF9-4DD8-8BB3-77B530FE1565@yahoo.com> 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-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [1.41 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; NEURAL_HAM_SHORT(-0.82)[-0.817]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_LONG(0.01)[0.010]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(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)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4Zj5m73sQWz3TMF X-Spamd-Bar: + On April 23, 2025 6:27:20 AM GMT+03:00, Mark Millard = wrote: >Sulev-Madis Silber wrote on >Date: Wed, 23 Apr 2025 02:04:28 UTC : > >> yes, 2 * 8g partitions on separate disks, so i have 16g swap >>=20 >> =2E =2E =2E >>=20 >> >> >Van: Sulev-Madis Silber >> >> >Datum: maandag, 21 april 2025 03:25 >> >> >=2E =2E =2E >> >> >> >> >> >> others don't get it at all and only suggest adding more than 4g r= am >>=20 >> =2E =2E =2E > >I have no clue if this will be of any help=2E > >For 64-bit systems, having total SWAP much greater than, >say, 3=2E6*RAM normally produces a warning about potentially >being in a mistuned state=2E They look like, for example: > >warning: total configured swap (477183 pages) exceeds maximum recommended= amount (466816 pages)=2E >warning: increase kern=2Emaxswzone or reduce amount of swap=2E > >If I understand right, adjusting kern=2Emaxswzone makes other >tradeoffs that I do not know the details of=2E Thus I avoid >getting the messages by adjusting the SWAP space size >instead=2E I've been told that the messages suggest a higher >likelihood of deadlocks happening while managing the memory >space=2E(Others may known what they are doing with >kern=2Emaxswzone adjustments and could judge the tradeoffs=2E) > >Are you getting such messages on your console or >that you can see from "dmesg -a" or in >/var/log/messages ? > >(The detailed multiplier changes some from system >update to system update=2E I can not report a fixed >multiplier=2E I leave margin to make it unlikely that >I'd get the notice across various updates=2E) > >3=2E6 * 4 GiBytes =3D=3D 14=2E4 GiBytes SWAP, as an example=2E >Then RAM+SWAP =3D=3D 4=2E6*RAM, so 18=2E4 GiBytes or so as a >memory space=2E > > >=3D=3D=3D >Mark Millard >marklmi at yahoo=2Ecom > > i'm aware of that=2E but last time i checked it only affects possible swap= fragmentation=2E i tried to tune it according to some suggestions=2E then,= others suggested it not being thing to worry about so i took those things = off=2E i couldn't find good information of this=2E would this even affect a= ny of my issues=2E unless i'm wrong, i cause zfs to use all my ram up=2E wi= th certain specific actions=2E kernel won't freeze or panic=2E it just give= s zfs what it asks=2E that's my guess=2E and this is outside arc=2E it's of= ten told as if arc tuning is magic=2E i think nowadays it's not needed=2E i= read it=2E i see it my earlier poor attempts were in https://forums=2Efreebsd=2Eorg/threads/server-freezes-when-using-git-to-up= date-ports-tree=2E88651/ it also has outputs and others were confused as well=2E but some had same = issues so i'm curious if that got fixed=2E needs extra low ram tuning=2E or needs= some fix=2E maybe zfs fix=2E maybe tunable fix=2E maybe defaults change, u= nless it ruins someone else's system=2E that i don't like either as if we need something in kernel to check that whoa, 90% ram is used just= to power zfs=2E maybe we need to slow down here=2E i can't tell where memo= ry went=2E all i know i had this=2E and other issues finally someone suggested limiting git itself somehow=2E but i don't think= this is all=2E hell knows what it is=2E now i encountered some other issue= s isn't this kernel's job, ideally, to manage all this=2E including reservin= g some ram maybe=2E i can't even find tunables for this=2E i spent ages sea= rching and gave up multiple times=2E maybe i'm missing something that (z)fs= expert could easily see=2E i see that low ram zfs has improved a lot someh= ow=2E so something improved maybe i'll just wait? i clearly have not much clue left=2E research is har= d=2E maybe i'll manage to wrap my head around zfs eventually From nobody Wed Apr 23 04:59:57 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zj6Nv0wGgz5slFM for ; Wed, 23 Apr 2025 05:00:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zj6Ns3sFDz3lCZ for ; Wed, 23 Apr 2025 05:00:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=EeC0OLxJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745384411; bh=kpiOMlDLosxsQG34Tz+vJdhDa///dV8VV7kVTAnCX5M=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=EeC0OLxJmIXqlBpvNKQJUw8LkU1aF4gKRDMDvMFkXzwdQ9ldzCuAZZeiqlQE2F9NYKBnRMbJypUnc3ki+0FwcyAS1+6dQbaareZW1abenzxWdsXPBmQt2+wnEEQfqQKdLc5UisBaQBx047itxe+DGQp513NfAd9KkaqZEs5APnTpQokweSJcow+gnv+KXQbphUbHBppt+ARHylId0XYVNLB4vCrPMDXJZm5Chfs+s23JgCCcIg89sMeCaZAkcq87SpHq6+sOLpobdSduo6bwv7Z8bjwfPtuxZ3UaCltaGywXrS24TtsQxXY3L6qsNIbtffKA3wvlxfU5Smy7XOmtng== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745384411; bh=ahZOsADnUMkL6IpFdJ6pl8cArZ7vfsEzbshdrARCsYM=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=CunCAnZ5OfDuoCo3XvDrQpt3U/8DCYgc0ZOt1Okmc87IoVifNSoiBuub28jn8oLK/5yzoFtfD7/rBEutJXqf1yQCRDHHPsAyrJnWBvRw0YgldEHapnY5vVgBbMkE+q14aOYZFYtosxYbeHoN3Y0MYuXmpe+bKsABCkTF8ETEupHXR75Oi57A79BagyfrWZYOsnqG9untm0eJG65vpRg1dFXfx7hSOVKE8sJzZz9SJVwlwbMn9335MePGgWcr2xwMa+LgLxFJkFrPFUR+DzhmJ8qYtHC4UQ08JUZJRAmbgrpHo86o4509X7S+GzE0vHVMgks2EghyfYYbFMJb/Rl1wA== X-YMail-OSG: TX_SjJAVM1l1ZMCqNag2.6reKd9PMO4g2MfRtsx25tNSge8diJHatJeKKb8OjEd DSuWLnmDbKEVnYSl..YWdxuWRiBWrxt.YnQJM31g8t40tUsu8hjefS5XJGm4NwRTHXPWavLKmAmX sWdfSrjs2DujbGsuyGjdQx3uVvzDltLGXbCzj2UroRUOiAeOz1HVzyLPlpMDnvITZRGbhAhcNRLg RURvMksjwlsVqWaOvJvoyRX_LaMecSmJUL5F0nyPnxA6XWWN4Zesz9rf9GxDf.DyRD99Z7sAfMBV MX012igc29wAK7MDcM2Ob0.P6oPfpOBfXQwjFgI370WcRqgQJAe_iXLG._4XJwqjpj1f7TNnX7jI e_kyYP9oxJAyQrtZYAKzMR79Veg85ibfmF71oQKQRl.kFElUQGHo81j4eCqAFponAFC3k255Gmwv Jgs2e.wot0ubbhK64PvmLlxeveyscyLrdFGjuP_Pe57wdU39MQxfQy_sLoNq0bSKBJIWAncR0biy 2Gg2ymRVO7GuQHbfBUW0ruJW_oWuALshjbyrFDoeZbM6FVDfKajrCDDXBtuETtB5fQAu_OKE.HFA _W8FfpiqBqqiboDHJ75XXnT14ophhYbkLO4t3GKWMa.jNvw9i0Sul_jYGxKQr2kBpKTSoGTZqL2D UZCbj73_pC.RpAP7y_Lrmpbofn5SwTxlUDz7uw1bpdK9Mq0H86oF7VtbMAkSd671K51nVEnJocJF IwCLErTRLSr7_DCohqLh1UZnz9CUlmiq1GZuam9l2JF6DSs4ZLFZNLbuK52FReLskBTH.ffWcYpF zkLpzivKTzM26SW3bYzNxpmETBFwk__vI19eFIfUYt_PBmlAVSU_LIFF8kcHKwjqtBEfCRsHUcqB 2ePFbQBH2IfC1fx4IWjMmANjm2C0m__ZaMw73xbMueaUWqCJF_J85ZwNKsrdzaSSetCQCK9Grn0E EOzz9RusINztYhIeEFFUoiIQZOSH3ajaCEeP_wA.NNv8mZpPUlwDyCUP0VZbh41wFsro2_aexXdj WNSvzDbUZoA6vO0PJssiX4HW.zOW7qNbNwqAgxm4rpz8b6FpHS7VkZr2P64sc4zVJicldlMKr7IY y4u0KgRccEOK.8m.8ftiRM3p6AcVqNsiqwNp2nw.JLilPIv0WQvJfNc2G.aAbWJwG49shKs3qvFB G3faCCPW2M3vnMKH4SANows4cJLKxC.3.wTOUwzotlZ0CjbuaS1kPtuBgJDcNy.CTAJNOhfhYyQ8 mW_18_FozGwDKOU6NiJxM9x3B4UWZNb4M5fwO9bRxkxfCadnAJZKuULfVDd755upoMTIDgk78gC_ 3JFHxYn_NKjnnvz8lhMaJ5.L.LFETlnmNbNcZv2PXD85aOsg.ko9au1HlFmyijWRuqKjG1KDc4EP Azep.l2tTAx_GlJYh9efYd52O1zzwe3smWHPDiKpMvL2POjHQ8xCVJXN0bt2qdjZHzajUzyHViqM 9OKUs6sVl0NsK.JY_MUVcKnPBEe9PMKIZAuTN95sOssM38AdjIUHJrAvh1eoIMuGdRN._x5mGK7I dOheC0psN50Ltv1ecHEWv5rebaHc6GAX6znjifggc_3x_Sw9AZs72cybcWxQWbtJnzue3nlzjZt5 teNLK58m3M9c_Cd9FF5dY4pUMovT7ednfyhMnTSqcOtitj9AL4AK8csQ3WBYGiQRkBJhPp49ME.y L5hbUFOLnyi5_ICKbGWfyzh_gJ83GBBuJm47ORJmwMRJtGUtyZT4YSTeCmqTGX9xqaAASgravQjK XsV21ABcBqchiHATDgbJl9Cy1gbX_Mfppx4A.THeBAYqFU0xvlRWnBauYEXRIiemUEzjsw856wpb 9lxFHaP_tQGPXNCRatl0szs6JJ7kd9fPYyZhIK_4aNdhfvrkgd6lIG8Ha.Ujqv00.kBpQQlTqteD ILt_k0.vwtmEwSMITJIQDd7JXEi0HZ5oz6XW.yoxytt5CkJp3dP_RruX0rHsPwRnQDIeoe1Bhibq hySNxD_xFjHTiszj9WZu3JjaDikly5Ryw0J7RnUaKl49zk23rZRfoJHzJw3TjQwwnZFGxR0niZpZ nZkK_1XOpUJoOxKn9EFEBkQXrXOOvKDzhgB_0.ZCU4b9_mnYgtnsrsrEiLjnrSCGriJXk7Yuaa6i DZIwQfGSlj_P9HTLTl3vbd4dMQR7hSnajMbsM.RYBq3ok1DEiHU_U4GKh2mv4hhEVZLGmflUK7wN 3Gm3qNU2tmjSx7Rrgs.stjXxDIBkD8KRBZGHNAWSR7UhHq6w09vDMX3Dvrr5_n02S7JfhAamhEQm nUQ-- X-Sonic-MF: X-Sonic-ID: 01d1649b-91e4-4c8b-b5cf-8cb37e7b1fb1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Apr 2025 05:00:11 +0000 Received: by hermes--production-gq1-74d64bb7d7-k2g2q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 75dd149c769462f7bf5bd630aa64f263; Wed, 23 Apr 2025 05:00:07 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: zfs (?) issues? Message-Id: <7FBFC21C-2E5E-409B-AACC-6C529F46B52A@yahoo.com> Date: Tue, 22 Apr 2025 21:59:57 -0700 To: freebsd-current-freebsd-org111@ketas.si.pri.ee, FreeBSD Current X-Mailer: Apple Mail (2.3826.500.181.1.5) References: <7FBFC21C-2E5E-409B-AACC-6C529F46B52A.ref@yahoo.com> X-Spamd-Result: default: False [-2.74 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.68.204:from]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.922]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_LONG(-0.32)[-0.321]; 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)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from] X-Rspamd-Queue-Id: 4Zj6Ns3sFDz3lCZ X-Spamd-Bar: -- Sulev-Madis Silber = wrote on Date: Wed, 23 Apr 2025 04:31:41 UTC : = https://forums.freebsd.org/threads/server-freezes-when-using-git-to-update= -ports-tree.88651/ That, in turn mentions: the remote console shows an unresponsive, frozen OS, unable to interact = with. If FreeBSD 13.4 can still swapping out process kernel stacks, you may want the likes of /etc/sysctl.conf to have: # # Together this pair avoids swapping out the process kernel stacks. # This avoids processes for interacting with the system from being # hung-up by such. vm.swap_enabled=3D0 vm.swap_idle_enabled=3D0 (I've no clue that that is why you lost control but it may be a possibility.) (main [FreeBSD 15] no longer does such swapping out of any process kernel stacks and the 2 settings have been removed.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 23 05:34:36 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zj78v2ZkQz5snCn for ; Wed, 23 Apr 2025 05:34:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 4Zj78t0JKQz41x7 for ; Wed, 23 Apr 2025 05:34:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="nsc/lYWi"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745386492; bh=gqbJ9VoojvJPZCp6zDWp9TqjVyfXZ9IGfZmY26NYIRQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=nsc/lYWivMIMqiR+YGgF9lryqnqMVIFxJl/WpG8E+a8AYznOYGAu7NVDCt3E+mG6agycVra4vwH6pZdJwewPlqhlI6/UJNNUPOpiJH2YhbP7pXkWhpQQi3GIHYyDe5S1GX0GihFgtIml69/NLxpybkqvvebdvo/fFDbiR+j9b5fW+y5JLQ/2aDYoTS/UQjQixDmBFFeAs9exHOOqISqD/9T6KbedV8GKjfURC+dmoGRUoLpA8stWgFj4POS1DooSl1nnAw8TKZnPQ/Yvh9FtDjkmavG99LZru1Zdv3Cs/Fdw3FX68sNsxBvIc63JK8CPcEVXXcIA3HUiniTNSo8BLQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745386492; bh=ucfYEjYjTfe6zWDcJ7SJtJkxuUBJUZO15Y0YRkLjBDF=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=GWeqF1Y+CsjOLDUuAqD/LIAgd3iQSYQCyHdg9dbT7rSSBwtNL/tyYbQueNLh7/YK9r86LGhcC3jQAvzDu5VO4yyusCOKA4rEGEB+heQV+F5an8fQhrmJ2PIlw3cIfOGA6YJ9zDKFIHYOmH34jm+6lRsDaLFlJ15yl3zP0BE9+3rjBmFe8cRjBmeZqyPyCJAVmVMjlDTtVAtLbZ/1w8/bVO/IvmYj0kWrX8SZfQlK9E2puX4Zg8tVWoKom6FRv74iu1IQ3E4rtvKth5eU/TPpD/JuuTXd7/Upa/hgw7qFl9G4azoU9+42z2+L4Gx9XFxrxSlXP9wpT4KpZFt/zjBrqA== X-YMail-OSG: iXllZV8VM1mtO1KZUGIR_rWoVBKzdZAFpxwpypBkjbLdvxmyEzFLq5gZaTnwlSR B5qr2e1YEZgLcthY.TSQHl0brtq4KunW4eEZfPtXhAt.KKgDvifj1cdAOTTcWbGngSKKScmrnhnI NScYaB8iDVyh3j6.ti9YygBqxTou56BLChZ4m4pzd_Teglpgdwlvp9TtRN9c1cF.NXK5dh6vzNEC 9YkjYUjI4IJ3h.LNSJSzBmaRQRwGPpLDs5QPud36SXmwTo110z7vARnElpUehenr5Y.B0x9gvfBJ E2L_Le2Zb2bPofPN8Va_t3gI80jhpH5P_SBjYfURiG3xooFSxuCo50QLCOjSzJ3zs3aora.PkwXf fO2v.19v1ZGSI1mFNDW54WErblZn8T1nTiAM._ui0vEMxqf9m6NJoBcYN7jGlhnxoOIzqt7zPWcG SrQ2asTh._5yhwXoTkzwj4lTX4xPjzsoym11UXcgGWZP7S0UN2Lsq4SkvP0hIY1M3onjBIoLUMhV bErhlxuV6T.YRWA_mmzzY5p5_w_HRdgIOGV2w0YKaefzj2bohOgb4uVkQFHArfiV7rJFcO1nIyxS RRBud3HRXQG_yqakmfQ39qAfZwrDsCc_GUaDD87NThL_Zl1BJbSF5rhFC0UzAGCAQDaDnS.lctSv HClVbdPwRkoOrnXcBMiTdNQxGLfd9ALDi.xtL8YZe5o0NsAD25.XaWcyARuYuqn.IyG7ZoPqfvXp Dt5.dirdTeAxnT3Y7oJ5X5Z.3LFUq2Iy0qD2siCUk80yFvxxCDbT7QCpnNttFmouwtpZeo8mSjl6 0toWzdMxOdEr2wuRnsHusP8pKVCcRh98_w47MiWoly6dV9KbThUGfgAiszzDllD41xzVLslJFW0U 1h0FX0xvNdeF5QlaTExkiDKozlw1mxjIDqsGhMysD8AFDsQimhRIlVs7_P_V3WeipTq3cnZ3xxB9 FXu_82RRVR8b9M1eLg2aCxzDM0F44ZA5r1d6q6eEpFB.Osr997EvkdbpFyMzLFudFBraq8bhekGM 7VPMS3Td7f3JcmJQh.PoM_jh4YhgaNsI7xtBFmvqw_mW1Knh_pOA6Fzs4PDZOx1L6uvqWrajBIpz evkBF8rYRra5Lwf2Rrj2KN2vbmIqGkS5ry7ozNFZbW4TT5eS6a9L5XdBoqtNEo26Z0l0.dwBlsV6 UiKMjYU.69LY5zZRjssNPnwwL.kYujChrBHG1Tf5vY1RzWRM7HYu8eGMb0l47v739_0Hu5vul7ab v59BjxAO4eagqYC4uxiQiIlhtSOZtmIueN0njk99iWxNgjgts0AJ.AQ.TH82rghmpp7umlwe8oAY ntwKWL8JU5l8iHcLe2OhJTykfiP_Ryt_qBVWqTRWUxU0RVny1dgK8A9VvaAeA6x8gnsiv0TlGylr ew8._34oQ0WHSO4bbh9gKtiUNXmLFh5m.VlexLVgC60IQIQuX3s4yiD00N40BMMS8vVFe.MiH23C Jz1cQH9Kc2ETrmib6cC4Y9KiVB6AGHVVxEDq9u7qqyH1ciY_d7ZwDQBENaH5Ai4cjva6ahqtvkuu 6Ve9oHWEieCJpqXT9ok7UVZ8DIUShn4jZUbn2dk2_YgHKYELE0o15g3RnnI7voWA1G1JZcKsrfDZ .FYcJo9BOGT.QEdALugcYkDzRSPG3lJld6cimy7w2b5j3JQes2VR4FBHK7A2R53qZHkEdZViFCzB REB9t6TAb6oKOVum5wOU68mnvfGQPjqNfXyv0bYM8y.0jK4Q4lD7GjICsUfABKmmG14NPkFWryyB _pHsz53qSoWGUAaCbQH7qyYGBoYT1kZCpOeTTqK9m0.IAHIyDjgWy3vLqY_ZqZqmJ9TG8QskuIAy jV53sbGX0Rk_b1nUZqqraVpfTR8I7RlZc1HRe35TUAI_iSD9YzQT6kVfXwzd4ZeJm9QkdID4lrDV 6pZ0dcWVDw3N7IqDNktbQzR751ZQk8ff0oJ3ShrNDICZeVb3i3mTHHGKIZW1VUJANrd9oSk_iItA KoLP4PgkpV5Oh5K40A9axt37M097sdw0Fo8gpW9_DFIU3xT92Nrk0RZB5.AIODwzLMqYFZ.RkFH. I8aXBcx3Lb04yoVKKPAjS2jd2M8Poef.Izu7ANJQv8IISjQ4g1o8TpPZmztYIGCKtxJVC6OcHK9I eIkAiODwr.MWIU6eiI5sX4je7HjfYN3wtik.oBnGCi3Dz4jzO0Yz_heZbwJwuboA1BfG_1fDrOGo _yXpiKDmx.znx84KPxEl64eKmfXbVSxVWzxZHEk6zY8eyYlVRZlmLaqRhtbEDoNReP0fZQl69Xwl Sqg-- X-Sonic-MF: X-Sonic-ID: 58037c75-979e-45ef-ba8c-d1a6fc66a51f Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Apr 2025 05:34:52 +0000 Received: by hermes--production-gq1-74d64bb7d7-4jn9v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b33a3e680f9580e643a09b22c64167c3; Wed, 23 Apr 2025 05:34:47 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: zfs (?) issues? Date: Tue, 22 Apr 2025 22:34:36 -0700 References: <7FBFC21C-2E5E-409B-AACC-6C529F46B52A@yahoo.com> To: freebsd-current-freebsd-org111@ketas.si.pri.ee, FreeBSD Current In-Reply-To: <7FBFC21C-2E5E-409B-AACC-6C529F46B52A@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-2.88 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.69.32:from]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_LONG(-0.38)[-0.382]; 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)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from] X-Rspamd-Queue-Id: 4Zj78t0JKQz41x7 X-Spamd-Bar: -- On Apr 22, 2025, at 21:59, Mark Millard wrote: > Sulev-Madis Silber = wrote on > Date: Wed, 23 Apr 2025 04:31:41 UTC : >=20 > = https://forums.freebsd.org/threads/server-freezes-when-using-git-to-update= -ports-tree.88651/ >=20 > That, in turn mentions: >=20 > the remote console shows an unresponsive, frozen OS, unable to = interact with. >=20 >=20 > If FreeBSD 13.4 can still swapping out process kernel > stacks, you may want the likes of /etc/sysctl.conf > to have: >=20 > # > # Together this pair avoids swapping out the process kernel stacks. > # This avoids processes for interacting with the system from being > # hung-up by such. > vm.swap_enabled=3D0 > vm.swap_idle_enabled=3D0 >=20 > (I've no clue that that is why you lost control but > it may be a possibility.) >=20 > (main [FreeBSD 15] no longer does such swapping out of any > process kernel stacks and the 2 settings have been removed.) Are you using a file system based SWAP space? Vs. a Partition or Slice based SWAP space? Quoting: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048#c7 on why it should be Partition/Slice based: QUOTE On 2017-Feb-13, at 7:20 PM, Konstantin Belousov = wrote on the freebsd-arm list: . . . swapfile write requires the write request to come through the filesystem write path, which might require the filesystem to allocate more memory and read some data. E.g. it is known that any ZFS write request allocates memory, and that write request on large UFS file might require allocating and reading an indirect block buffer to find the block number of the written block, if the indirect block was not yet read. As result, swapfile swapping is more prone to the trivial and = unavoidable deadlocks where the pagedaemon thread, which produces free memory, needs more free memory to make a progress. Swap write on the raw partition = over simple partitioning scheme directly over HBA are usually safe, while = e.g. zfs over geli over umass is the worst construction. END QUOTE Note the references to ZFS and GELI. Your forum notes reference such. A separate tunable: in case "was killed: failed to reclaim memory" is involved but not reported/recorded: in /boot/loader.conf # # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 Separate question: why did some forum top runs show qemu-system-arm threads? That could be a significant competition for RAM+SWAP. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 23 06:55: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 4Zj8xY63QLz5svrn for ; Wed, 23 Apr 2025 06:55:13 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4Zj8xW4B7Wz3Ry1 for ; Wed, 23 Apr 2025 06:55:11 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=vvDAHAeL; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1745391308; bh=2z6mflP69h3Yi2rhdCjrELe3ADMAvcnctnvqqjx8e/I=; h=Date:From:To:Subject:In-Reply-To:References; b=vvDAHAeLKd0hZLpAyJUijUfJ9U2vRqeki+oreA78LHbLBvZLgb5p7ZcPj4mEwoerf QHiAaNIsWrtBeR/UaESp1qFDWUkJVcK1a74UY4nneU5mwajCLhbOJuR3TzqO7L0/5y QHr3htzF5C+C40PtwAK15n0l8/7PaTTiL+No/FwaTdOtepK3yXRoPj1QEZLJCxek17 upN/wbRcHFiKCQOg/Pttj0f+oML+VYtdKyV0G2fbrgDFGMox4jrgNJ4+YTlli2xi6/ wnalfmoa2jT56zQGpVmemI/mKWVXpaQsvOfOjDC+meO3OnmRlnblj6nXZH9mo6j/8m rbLd9XLWwaqDzi8nfSS9xX6UPyobZh5EuHK/0efuBYvzfwaWenHnlwsJZOOZWN+oOA DbPzC+/rd9GRU27qw5MKAtxMZLTI6VLg984JUZrr2lsd6+FFzI5RdRScQi4rtowMZq USe7kS7gKDTVm7x9sfaeW3bFoR+FLkA//R77LYLRfOcoBx/vWNd99h/iBVXWQdiWZb RBMva0dj6tTIt9T35mCoLE2iXF3FrSRVsaCNDvF4/0mW9R6SwZNGcw1OIOwbFPR0aY 92q0HeSuLhdgeIC7nKrnFQbaB8x5MfuRY4JS5anPt85VLqDLQIUmZgP8txa7t7jgHg 7ZJNYWwyjKlHgjQ1lC+LXrE0= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id 10D555B4495 for ; Wed, 23 Apr 2025 09:55:08 +0300 (EEST) Date: Wed, 23 Apr 2025 09:55:06 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: zfs (?) issues? User-Agent: K-9 Mail for Android In-Reply-To: References: <7FBFC21C-2E5E-409B-AACC-6C529F46B52A@yahoo.com> Message-ID: <2DED0D7F-2680-4826-A3B3-28425E26FCAB@ketas.si.pri.ee> 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-Spamd-Result: default: False [1.36 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; NEURAL_HAM_SHORT(-0.78)[-0.777]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.08)[-0.081]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(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)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4Zj8xW4B7Wz3Ry1 X-Spamd-Bar: + On April 23, 2025 8:34:36 AM GMT+03:00, Mark Millard = wrote: >On Apr 22, 2025, at 21:59, Mark Millard wrote: > >> Sulev-Madis Silber wrote on >> Date: Wed, 23 Apr 2025 04:31:41 UTC : >>=20 >> https://forums=2Efreebsd=2Eorg/threads/server-freezes-when-using-git-to= -update-ports-tree=2E88651/ >>=20 >> That, in turn mentions: >>=20 >> the remote console shows an unresponsive, frozen OS, unable to interact= with=2E it wasn't clear what happened there=2E but here icmp echo replies still ca= me back last i tried=2E i didn't try to do it deliberately once i found out= it's git >>=20 >>=20 >> If FreeBSD 13=2E4 can still swapping out process kernel >> stacks, you may want the likes of /etc/sysctl=2Econf >> to have: >>=20 >> # >> # Together this pair avoids swapping out the process kernel stacks=2E >> # This avoids processes for interacting with the system from being >> # hung-up by such=2E >> vm=2Eswap_enabled=3D0 >> vm=2Eswap_idle_enabled=3D0 would it be related here? >>=20 >> (I've no clue that that is why you lost control but >> it may be a possibility=2E) >>=20 >> (main [FreeBSD 15] no longer does such swapping out of any >> process kernel stacks and the 2 settings have been removed=2E) > >Are you using a file system based SWAP space? Vs=2E a >Partition or Slice based SWAP space? just 2 gpt partitions > >Quoting: > >https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id=3D206048#c7 > >on why it should be Partition/Slice based: > >QUOTE >On 2017-Feb-13, at 7:20 PM, Konstantin Belousov wrote >on the freebsd-arm list: > >=2E =2E =2E > >swapfile write requires the write request to come through the filesystem >write path, which might require the filesystem to allocate more memory >and read some data=2E E=2Eg=2E it is known that any ZFS write request >allocates memory, and that write request on large UFS file might require >allocating and reading an indirect block buffer to find the block number >of the written block, if the indirect block was not yet read=2E > >As result, swapfile swapping is more prone to the trivial and unavoidable >deadlocks where the pagedaemon thread, which produces free memory, needs >more free memory to make a progress=2E Swap write on the raw partition ov= er >simple partitioning scheme directly over HBA are usually safe, while e=2E= g=2E >zfs over geli over umass is the worst construction=2E >END QUOTE > >Note the references to ZFS and GELI=2E Your forum notes reference such=2E > > >A separate tunable: in case "was killed: failed to reclaim memory" >is involved but not reported/recorded: in /boot/loader=2Econf > ># ># Delay when persistent low free RAM leads to ># Out Of Memory killing of processes: >vm=2Epageout_oom_seq=3D120 helpful here? > > > >Separate question: why did some forum top runs show >qemu-system-arm threads? That could be a significant >competition for RAM+SWAP=2E it's small vm yes=2E but it behaves well=2E part of it gets swapped out=2E= then back in, so on it's all funny, i might be using more things in that machine than i have r= am for=2E but it just gets swapped out=2E swapping it back in causes delay = in that thing that needs that=2E like always i still think git does something here=2E if i don't touch git, everything = is absolutely perfect=2E why git? if i restrain it from config, it seems to= not cause issues=2E except maybe they are hidden now whatever happens, it happens in memory that is impossible to swap out or i= s not preferred to swap out git is not swapping and then being killed=2E that's not how it will affect= the system=2E i think i helps zfs to take all memory and either throw unus= ual errors, like that single case=2E or just cause total exhaustion what's fun is it never appears elsewhere=2E everything else seems to work = as one would expect it to work when low rammed > > >=3D=3D=3D >Mark Millard >marklmi at yahoo=2Ecom > > p=2Es: i also found https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id=3D231457 where people experince (maybe) similar issues many years ago is it active issue still? From nobody Wed Apr 23 07:58: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 4ZjBLq37cmz5t1PV for ; Wed, 23 Apr 2025 07:58:43 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx0.riseup.net", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZjBLp2XH3z3s6K; Wed, 23 Apr 2025 07:58:42 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=Lhsg9XjF; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.6 as permitted sender) smtp.mailfrom=agh@riseup.net Received: from fews01-sea.riseup.net (fews01-sea-pn.riseup.net [10.0.1.109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4ZjBLn0Cr1z9sJW; Wed, 23 Apr 2025 07:58:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1745395121; bh=0NitR13v/8Jovp5VCsRcIW1qXY9d0EBJuW7RsW0M+sA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Lhsg9XjFHfKI8fNB6dx3gc2UkN7ZAsYhSkYgd7deCgDhSaL9+okJG3alyAbXF9wzJ ewbO78wmcEV3V2Sux4rrRlXSdEjl+lF5QwruKfWMeulG3xZiMsNsUto8LpV8DwPF/T ZI7Zf4fkdYYjs4mE1Y8oJLw/NDCctjM4n+s4LPqc= X-Riseup-User-ID: 19A27D82563518ABC52916FD5FEB3A784DA2B40522BB71ADAB2BB082B39C9B01 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4ZjBLm5yybzJryZ; Wed, 23 Apr 2025 07:58:40 +0000 (UTC) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Wed, 23 Apr 2025 07:58:40 +0000 From: Alastair Hogge To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: freebsd-current@freebsd.org Subject: Re: etcupdate failed to build tree with read-only /usr/src In-Reply-To: <86r01q6l80.fsf@ltc.des.dev> References: <86plhdb9yf.fsf@ltc.des.dev> <86r01q6l80.fsf@ltc.des.dev> Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-5.10 / 15.00]; DWL_DNSWL_LOW(-1.00)[riseup.net:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; R_SPF_ALLOW(-0.20)[+a:mx0.riseup.net]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.6:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RECEIVED_HELO_LOCALHOST(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[riseup.net:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; RBL_SENDERSCORE_REPUT_BLOCKED(0.00)[198.252.153.6:from] X-Rspamd-Queue-Id: 4ZjBLp2XH3z3s6K X-Spamd-Bar: ----- On 2025-04-18 14:24, Dag-Erling Smørgrav wrote: > Alastair Hogge writes: >> Hmm I did try $(etcupdate -B), and I recall it also failing, so I >> updated another host, and used -B with etcupdate, and it failed for >> another reason: >> [...] >> ld-elf.so.1: Shared object "libmd.so.6" not found, required by "mtree" >> *** Error code 1 > > This is _after_ installworld, right? `etcupdate -p`, then installworld, > then `etcupdate -B`? Correct, and it fails in the same way as originally reported, and also with the patch provided in PR 286072[1]. 1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286072 -- To good health, Alastair From nobody Wed Apr 23 09:38:48 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZjDZM3JcTz5t7SB for ; Wed, 23 Apr 2025 09:38:51 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZjDZM0l7gz3gJb; Wed, 23 Apr 2025 09:38:51 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745401131; 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=g2UrtzBgODh00tAmgAOtQX/+FTRp+OaYjnxgmy85skM=; b=cRx3KXWuju0tJiquxXQ1YegvIZXfNWE9jWf1z6atBOBSxkV8CGVL4zd16xiX3VhoaB9D+f d8MaeXryt3lSwZ+PfazgjPB3kLWvpPEvn9cflzXUKCZ9r2f4WSmIx1ycAuXIGNxx1bwDOc yR4/Nu+XYcrAiwfBReGqAMZQ09OLrgjtrvQ2dRg/XRwGvc2NiztRLXalceL/Y8v3TXkoHe zW3+TNsRhNHQjna/6qwmt50rSvnJNzuBCMgdYOfezCLCGIfdfBhxs3jk/lK6MZt/QVs+T6 CfCyl8/HvlFBE+oIoJmYV3cKmwLS6Ndsozb347F6+gP2E2e2hKclUatWUhmk9Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745401131; a=rsa-sha256; cv=none; b=Ui3w3fVnNX9l5tKEKkyhxE2YLIsfXmrogc6S7xRsCVm75vzeY4+qkXqfAuMXGH79UyTbX+ h+dtxrmi4tXlJRRcKR0u6t5LUojk01aaBmXimw8OoyxUTlgdNoVlEdbiiTYEjGUcroue2H +ZF8g0o7a6ACOM4LAPDxs/Rm9QGStQ5SLnsivx9zTVk0At4jhEK7SXLSh6cXTQYCIuTNXg az43HmnJoTl5YBHGOXF5PxFrcLrtK32zWLVeBbLzQsKn2LBkI/otzOnScg/CxtDY5iusEl FAhN9WKNOoJHMWTE/ycOg2ZDDX/Z72FZXxmsu12UxhSquJUNjOdg19AbXBmnwQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745401131; 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=g2UrtzBgODh00tAmgAOtQX/+FTRp+OaYjnxgmy85skM=; b=OJARSUSJhgmhzMk5NKdrebfliHDoGygLeddv1cdevtRb1ElIwNcTbFbOWYoFu1KRD1lYmH TXbhpw4DDWBfa/45WheoSAQFV/W3RuDEWw/8BfcTU0rTIo4GfbWULqhj+ytojyPg1h4ZuF SXJRXArmGAhzYnxyELRC+78yZ9sn4AiLWNm+w42mG5lAX1V9WG0PoukQMMDyNcF6lumYlD +zQldFRzaWThp/FvV/xrv+KG3l6ktVK11rFDAxLOX5Dm5XVNeMI2XLTjiwlY4WgKHDy8gx j7eNxQlNW5pY2dTaAzdguZZzOOcqwy4cYLVJV1jyr5UrF8SMgjfCYP6pP29bMg== Received: from ltc.des.dev (88-177-82-251.subs.proxad.net [88.177.82.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZjDZL6Jh4zKVn; Wed, 23 Apr 2025 09:38:50 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 8FFD2FAC08; Wed, 23 Apr 2025 11:38:48 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alastair Hogge Cc: freebsd-current@freebsd.org Subject: Re: etcupdate failed to build tree with read-only /usr/src In-Reply-To: (Alastair Hogge's message of "Wed, 23 Apr 2025 07:58:40 +0000") References: <86plhdb9yf.fsf@ltc.des.dev> <86r01q6l80.fsf@ltc.des.dev> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 23 Apr 2025 11:38:48 +0200 Message-ID: <867c3bw72v.fsf@ltc.des.dev> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alastair Hogge writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Alastair Hogge writes: > > > ld-elf.so.1: Shared object "libmd.so.6" not found, required by "mtree" > > > *** Error code 1 > > This is _after_ installworld, right? `etcupdate -p`, then installworld, > > then `etcupdate -B`? > Correct, and it fails in the same way as originally reported, and also > with the patch provided in PR 286072[1]. This shouldn't happen, but it's unrelated to etcupdate. What do the following commands say: find / -type f -name libmd.so.* 2>/dev/null find / -type f -perm 0111 -name mtree 2>/dev/null and for each file the second command finds, e.g. /usr/sbin/mtree: ldd /usr/sbin/mtree DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Wed Apr 23 14:26: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 4ZjLyn4015z5tRw9; Wed, 23 Apr 2025 14:26:57 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 4ZjLyl4yTNz4K11; Wed, 23 Apr 2025 14:26:55 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=PcHibe+W; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5e5e8274a74so9792986a12.1; Wed, 23 Apr 2025 07:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745418414; x=1746023214; 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=d1KeONCQWUYFIvnfie6nYKpl4CB4DIsccguQ4ghCXmw=; b=PcHibe+W5fO2AxwRL8oBXNoxA2aZiR0ogxbZd3cXaVMPgHirKZOfO+6j9G78cs5oXK rVRAR7C1+rkRIBEUzI8hak0BycfzgNlA8dhq9kfMSE0nSsP67zxS33MUUt4YIFdBvG61 diEUPk7N/18CftZ/HGjzalmRgayQwrEA2Fv3ScAyR/mlpaubvrmBQofvQYjgGP13MrxM 9ZwtKm1wB1mJ88+L5HuRsrKYQNoJci6EDUz17q+/O+PHcR8QyT/g700MygH0M2xpVBy9 kyaXG2+R/652JC2uzPChfNfbAy2KYFCyke1goUcmWHlNhgJLXrxAsLCIZS1j560WJj9e BZYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745418414; x=1746023214; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=d1KeONCQWUYFIvnfie6nYKpl4CB4DIsccguQ4ghCXmw=; b=I2RjaZTCMHjAtdfTftzICAvzRnvMmL7Ag0bkPfEV0kzd1S2/e2cnpYEM1p4431Zp+O NrMuKa3ym3WYNA2R1CkxKcM3q0ASW79alUZgNWuB26Wp6zR45CLhXbbKIHKomlV8tmPI KS+/kn8oAzdYwattcqwie5+NANeWZk7/2YyI56oTNWqsFsoKQGLWXJYFkPSu5pm75d2m AOErYCCrrMQSJT6PC30+aRvINM9/MUiprG0kD/C6qgawm7c9B4x2/w4/iQlQXuEraN87 tq4ef40GXdECvGEkC8+8wCyLSJI7RVdyk3cMdozVHEsSfxhs+a/8X+VeylEOzR9vxuOz RppQ== X-Forwarded-Encrypted: i=1; AJvYcCUO/BIfbrQAYRUBxzSrohdXpHBIuFRk4Y5IwhyBV7LH/Fap9uOOWiXOpBOm+bQV35WusCtptMwn/wW3TSszA98=@freebsd.org X-Gm-Message-State: AOJu0YxwR6GC1IW+fHipV3GL4HVjXexTikP6tZWnE6tkCDxHY/U+SOS+ HjheXk6+wu14lePuep8MZfMq1Pbt9/Z7a+h9w6YAdvlsU6KuGzHor9/K6CEZL9/wT73KZRTlDkr j/BWiftv/2eStowae2c7IMThsAw== X-Gm-Gg: ASbGncsgpWRDfgyhK9BzwnzgSi+t/CrRIH/B39faB5xA/AHRvXbwZ8eNhURkP3NJNVq 1K8rfDINnoVV86xyXljrs/tEkm/PT2Huw5VACqDrRbtufuoMmNyODC8JS6rQz9zUhfpriBBN5IA PcSrl80ufJTlQCS23bDTr2XHzo96yA3BFD5JA/AKs4q7eUeD1ql9b9 X-Google-Smtp-Source: AGHT+IG+BmwklA+iDgRYpBKXHGJa4Em1PDyxIqJ7YeTLDNPfqyeoHGNpzrnnylSyLh7/yYMjolMCGtRi4GMKyqgLu9U= X-Received: by 2002:a05:6402:120f:b0:5f6:c5e3:faa1 with SMTP id 4fb4d7f45d1cf-5f6c5e3fd09mr3675539a12.32.1745418413378; Wed, 23 Apr 2025 07:26:53 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Wed, 23 Apr 2025 07:26:40 -0700 X-Gm-Features: ATxdqUFvvvHXMgdnx5xQ9bfebQFaDi59XMAoyBnnecYReTRgsQyi59xKAeaOOoQ Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Cedric Blancher Cc: freebsd-arch@freebsd.org, FreeBSD CURRENT , Lionel Cons Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.38 / 15.00]; NEURAL_HAM_SHORT(-0.98)[-0.982]; NEURAL_HAM_LONG(-0.87)[-0.866]; NEURAL_HAM_MEDIUM(-0.54)[-0.537]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from] X-Rspamd-Queue-Id: 4ZjLyl4yTNz4K11 X-Spamd-Bar: --- On Wed, Apr 23, 2025 at 3:10=E2=80=AFAM Cedric Blancher wrote: > > On Tue, 22 Apr 2025 at 13:10, Rick Macklem wrote= : > > > > On Tue, Apr 22, 2025 at 3:34=E2=80=AFAM Cedric Blancher > > wrote: > > > > > > On Sun, 9 Mar 2025 at 00:02, Rick Macklem wr= ote: > > > > > > > > First off, I cross posted because I don't think many read freebsd-a= rch@. > > > > There seems to be a nice market for Solaris style extended attribut= es. > > > > Since ZFS is already wired for them, adding the basics is pretty > > > > straightforward. I am not suggesting that they should replace the > > > > current FreeBSD extended attributes. > > > > > > > > For those not familiar with them (I am not very familiar myself;-), > > > > a Solaris style extended attribute is in a directory that hangs off > > > > the file object and the entries in the directory (the attributes) c= an > > > > be manipulated with open/read/write/lseek just like a regular file. > > > > (They can be as large as a regular file, but there is no atomicity > > > > guarantees.) > > > > > > > > At this point I have a couple of rough patches: > > > > https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part > > > > https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 pa= rt > > > > > > Any timeframe when > > > https://people.freebsd.org/~rmacklem/nfs-xattr.patch will land in > > > FreeBSD? > > I was going to wait until zfs-xattr.patch makes it in, since it is usel= ess > > without the zfs-xattr.patch changes. > > tmpfs does not support named attributes, right? That is correct. Only ZFS for now (and maybe forever). > > > > > I could do it sooner, if that makes things easier for people? > > Yes, please > > > > > Btw, I had the semantics for O_NAMEDATTR different from Solaris's > > O_XATTR, but that has been changed now. > > I also have a "runat" command. It can be found at.. > > https://people.freebsd.org/~rmacklem/runat.c > > Thank you :) > > Ced > -- > Cedric Blancher > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur From nobody Wed Apr 23 15:16: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 4ZjN3x4Tb5z5tWGc for ; Wed, 23 Apr 2025 15:16:29 +0000 (UTC) (envelope-from che@bein.link) Received: from mail.bein.link (bein.link [37.252.124.82]) (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 4ZjN3w4nq5z3XZR; Wed, 23 Apr 2025 15:16:28 +0000 (UTC) (envelope-from che@bein.link) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bein.link header.s=mail header.b=SmWL14HF; dmarc=none; spf=none (mx1.freebsd.org: domain of che@bein.link has no SPF policy when checking 37.252.124.82) smtp.mailfrom=che@bein.link Received: from [192.168.1.11] (unknown [213.230.118.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.bein.link (Postfix) with ESMTPSA id B0ACF23F883; Wed, 23 Apr 2025 15:15:32 +0000 (UTC) Message-ID: <93f26c93-2714-4e0b-a4d2-78eb3680bd35@bein.link> Date: Wed, 23 Apr 2025 20:16:18 +0500 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: April 2025 stabilization week To: Warner Losh , Gleb Smirnoff Cc: freebsd-current@freebsd.org, src-committers@freebsd.org References: Content-Language: en-US From: Maxim V Filimonov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=bein.link; s=mail; t=1745421333; bh=Chn489kNqBKyDtnT4tvekxgjIKg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=SmWL14HFs0pUuq8XABqxiGV0t8XZhU418zySi+1H1SdZqEO43phtlZbW38I8/vmnVxEDvt4eWclCmBzpM8PD2wd0ZTOWzbPGF8ZdgxtOhG4wGYRpMutYDWeAcJl41Gv636I7hnK2nlY2bCz63+TfuQTgaje1mUxZ+sU5Tcr2/fI= X-Spamd-Result: default: False [-1.08 / 15.00]; NEURAL_HAM_LONG(-0.52)[-0.516]; NEURAL_HAM_SHORT(-0.29)[-0.294]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[bein.link:s=mail]; NEURAL_HAM_MEDIUM(-0.17)[-0.166]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:196752, ipnet:37.252.120.0/21, country:NL]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; DMARC_NA(0.00)[bein.link]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bein.link:+] X-Rspamd-Queue-Id: 4ZjN3w4nq5z3XZR X-Spamd-Bar: - Hello Warner, I've encountered the following issue: drm-kmod refuses to build, complains about vm_page_next() not being defined. Also, when I tried installing drm-kmod or drm-66-kmod packages, the kmods didn't want to work, complained about some symbols not being there. There does exist a fix exactly for that, tho: https://github.com/freebsd/drm-kmod/pull/348 I compiled drm-kmod from that pull request, and everything started working immediately. On 21.04.2025 19:22, Warner Losh wrote: > Please note: Gleb is on vacation this week, so I'll be coordinating > stab-week this time. Please be sure to cc me on any problems you > encounter. > > Warner > > On Mon, Apr 21, 2025 at 2:00 AM Gleb Smirnoff wrote: >> Hi FreeBSD/main users & developers: >> >> This is an automated email to inform you that the April 2025 stabilization week >> started with FreeBSD/main at main-n276625-d4763484f911, which was tagged as >> main-stabweek-2025-Apr. >> >> 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-Apr 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-Apr >> >> If you want to use only the official FreeBSD repo, then update to >> the revision: >> >> git pull >> git checkout d4763484f911 >> >> 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 -- wbr, Maxim Filimonov From nobody Wed Apr 23 15:40:44 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZjNc312pGz5tXsp for ; Wed, 23 Apr 2025 15:40:51 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (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 4ZjNc16chQz3nvl for ; Wed, 23 Apr 2025 15:40:49 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b="H/rTM1gs"; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=LD2kKjuZ; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 202.12.124.154 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id AEED3254029D for ; Wed, 23 Apr 2025 11:40:46 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Wed, 23 Apr 2025 11:40:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1745422846; x=1745509246; bh=usUHmg6SLM /Gicg0OfUccFLpfjrax61qj/mP4YG+oCA=; b=H/rTM1gsBm8IaeIc7fl+NfgJxi pzADXrobn3srxfhXg3ESRAMvF0s2cx5CcaXDj6vgsuGDYNSsJN/Ov8GlrpToBn03 5e36CO3JFMFfLYFYTXeQAj9vQMHc+WdsqFGohWsQDT0iw2lDQeyEql5O5Fwr0M5e 3x8iC8/51hqWustNLvCKI1c/8zyH92O1ak85YDV6GzntK/jNvXRulvV0CfZ8E1A1 mC/WU8AbByGA952y/CeGjQ5TuUBYACsw5bU6PLbF8ENHLnIV+Zi+HCGN1eGmYe7+ AME55tJLC3RIBGZ8wBxhDKkD4QR6XYRPZBZRoK3d+YK0JRa6hWgJej/R8Phw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1745422846; x=1745509246; bh=usUHmg6SLM/Gicg0OfUccFLpfjrax61qj/m P4YG+oCA=; b=LD2kKjuZSrMK97O56tN6IlDhc0Zr4IRc60L1iUVG2UFMnfZ7Ta/ PtWSn8gbuR7qotQSHvWxc36xG5dpfF4JHSxeCAmh3il1XjZ4gmWjqSPMw/lYqnNo suB8bMlpgyUnokopGx79dCNnkQVuQd2C+n4DMKUN/oEkfK3UWHQqKoecTkEtvIjb uaKm4TK6jhNqX6yLTzFmQf2yq70Et91bbIeNP1FT4xK5nC0pn8U/V8u1pPHeYMmA 3Y4A3GDrnmOxElWzeHjb4RB0VfDQR9y+hD90nzbQSD/jMSUtOTKCyfV0zu2ouJMG c5jM80Gh+TUTG1RmQ5LTMVAiDZcILaKmqDg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvgeeileekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhf fvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehf qdhmrdhfmheqnecuggftrfgrthhtvghrnhepkeeluddvlefhieelfefggffhffektdehle elgfdugfdvgeekjeejuddtheehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepud dpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghn thesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 23 Apr 2025 11:40:45 -0400 (EDT) Date: Wed, 23 Apr 2025 16:40:44 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: zfs (?) issues? Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> X-Spamd-Result: default: False [2.66 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.99)[0.993]; NEURAL_SPAM_SHORT(0.66)[0.663]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[202.12.124.154:from]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.154:from]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[f-m.fm]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:151847, ipnet:202.12.124.0/24, country:AU]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MISSING_XM_UA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4ZjNc16chQz3nvl X-Spamd-Bar: ++ On Mon, Apr 21, 2025 at 04:25:16AM +0300, Sulev-Madis Silber wrote: >i have long running issue in my 13.4 box (amd64) > >others don't get it at all and only suggest adding more than 4g ram > >it manifests as some mmap or other problems i don't really get > >basically unrestricted git consumes all the memory. I see symptoms like this on very slow media. That media might be inherently slow (like microSD) or it might mean the hd/ssd is worn out [1]. Programs like git and subversion read and write lots of small files, and the os/filesystem might not be able to write to slow media as fast as git would like. [1] observed failure mode of some hardware, where writes just get slower and slower. [2] the workaround where the machine *has* to use micro sd, in my example, to update ports, was to download latest ports.tar.xz and unzip it, rather than use git. [3] test hd performance with fio (/usr/ports/benchmarks/fio) -- From nobody Wed Apr 23 18:09:56 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 4ZjRw936K8z5thrD for ; Wed, 23 Apr 2025 18:10:01 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZjRw86Nshz4862; Wed, 23 Apr 2025 18:10:00 +0000 (UTC) (envelope-from avg@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745431800; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ScOr8ad3CFgM0bqIqoEcGCigV4dSpvEyjlBkfQKGFsk=; b=VDqM70/+Bltzwmj0AkMfJ4YxuXgbKXVLafqRQKwYz5pYvBSZ4mzIzth0TZCacrOlLDK3Uq yZlKrTXaiplDRH0nM6wR8OGC51CZ8L+xyGluV6rth7OxUx/tKOuVCJ1QmczKrSyx5AjTCg BO07qZT2l6La0tp/UOqGS+RDxXqOp4KQyNo09P/UnJCCKwQIzB/Dwn2M3SUWNR8Jsic7B/ Y4c9yC1BZ/lsEJmNIeGSREeESxeoTTOVcErFnyUcVGbd3P7tFkOdL0XUBXg7IY0A9BR/oB lny0BjC12RPdQb5x0sbD174mCC7K/oTIjHvDOlElkVe97VsIS4SOzsl/CnGunQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745431800; a=rsa-sha256; cv=none; b=FW6JrRxekqrLNFBsPKQKhgAslEI0yFB+imW0CUkTbFoNghw5Gx+bo8jCpEBN+eKyvrs8e9 H4caw5rgWeaRux2aiWXpQe3Sz0fjBsHQ3/4Kdn7JSbjKxqhMqMpNxLflMFzFR6ETDjYbsv 2M+939UHEa4Yst7BXvNUiHAkxsGCXmYn6FkozCC31ao/dk4wqwOeHADRF2HLBjyz4bNDyi lE3C1AUMMXMLaXI8HbSViAlzTmCFLombd7/NUESd1uMfQ1TdU3bfJwplLQo6OWuQ/D5KzZ SIhW82Uq7+82pW3pLDa8RFHTTQ7g0RqV78Dv6l3CG44etZxbyK7mI5yCpJZjBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745431800; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=ScOr8ad3CFgM0bqIqoEcGCigV4dSpvEyjlBkfQKGFsk=; b=Yy/0qETE0jouBWaTQ2ocr/heSuGcQHkJPMVGSlITMXE8MB8YO4ZKGlvb7FIQPoxPqmKCpg uR/4tSbhickGKcIZtobv2o8ExGd2sNCJHSd9F3Hip+zhw60ApGIKIzdEkAz9hSjWJGmxvJ 8+tmsiZ9QxwDgu50ThkuC6InIhR0FJ73QZ3q9I8jiEqYnTsCnOb/xLFcH2mHgO6HtfvEmO FRzjoPyazcvK0HV0qnTMgXnYAgsoBy3ZMIpCDJ/YjlBMS4yJbMaDYOjXWbH2iTOCAHlX4q J12jO8xe0GB5VX/sUB+CZlH0qJyMaSxGilNMFz1qFzWC4cI4SMxo3n9GbMGQWg== Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZjRw836SWzmQB; Wed, 23 Apr 2025 18:10:00 +0000 (UTC) (envelope-from avg@freebsd.org) Message-ID: Date: Wed, 23 Apr 2025 21:09:56 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Andriy Gapon Subject: Re: RTLD_DEEPBIND question To: Konstantin Belousov Cc: FreeBSD Current References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> Content-Language: en-US Autocrypt: addr=avg@freebsd.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 19/04/2025 13:29, Konstantin Belousov wrote: > On Sat, Apr 19, 2025 at 01:25:28PM +0300, Andriy Gapon wrote: >> On 19/04/2025 12:39, Andriy Gapon wrote: >>> From a quick look at the code, should we try to resolve the symbol in >>> refobj itself when it's marked with deepbind? >> Oh, and it looks like objects loaded under the "deepbind" object (e.g., >> needed objects) may not be aware that they are in the deepbind sub-tree? > > But should they? That's a right question. I have been reading about RTLD_DEEPBIND and Solaris flags like RTLD_GROUP, etc at the same time. I guess that's why some things got "fused" in my mind. So, I started believing that the concept of shared object dependency groups also applies to RTLD_DEEPBIND. But that's not documented to be so, at least, in the documentation that I could find. There are some in-depth documentation on Solaris run-time linker and its handling of various options. But for Linux RTLD_DEEPBIND I could find only manual page references and they only say that deep-binding applies to to the object being dlopen-ed. I am not sure if that's how the option actually works on Linux. I allow for possibility that the manual pages omit (or, at least, do not spell out) some details for brevity. In any case, I believe that the proposed patch is correct. But I think that it would not help in my case. I have: mdb -[dlopen]-> dtrace.so -[needs]-> libdtrace.so. And it's a symbol in libdtrace.so that gets resolved to mdb instead of libdtrace.so itself. The patch would affect how symbols in dtrace.so are resolved if I understand correctly. > Lets start with some minimal intrusive change: > > commit b4f4feb883a1be1d4ca3867f49baa20ce0c13d8d > Author: Konstantin Belousov > Date: Sat Apr 19 13:26:58 2025 +0300 > > rtld: symbolic and deepbind are equivalent for the refobj > > Reported by: avg > > diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c > index 2346c6eae9f6..8ea6afb43752 100644 > --- a/libexec/rtld-elf/rtld.c > +++ b/libexec/rtld-elf/rtld.c > @@ -4679,12 +4679,13 @@ symlook_default(SymLook *req, const Obj_Entry *refobj) > */ > res = symlook_obj(&req1, refobj); > if (res == 0 && (refobj->symbolic || > - ELF_ST_VISIBILITY(req1.sym_out->st_other) == STV_PROTECTED)) { > + ELF_ST_VISIBILITY(req1.sym_out->st_other) == STV_PROTECTED || > + refobj->deepbind)) { > req->sym_out = req1.sym_out; > req->defobj_out = req1.defobj_out; > assert(req->defobj_out != NULL); > } > - if (refobj->symbolic || req->defobj_out != NULL) > + if (refobj->symbolic || req->defobj_out != NULL || refobj->deepbind) > donelist_check(&donelist, refobj); > > if (!refobj->deepbind) -- Andriy Gapon From nobody Wed Apr 23 18:56:12 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 4ZjSxV6CFWz5tlJG for ; Wed, 23 Apr 2025 18:56:14 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZjSxV4hmRz3d30; Wed, 23 Apr 2025 18:56:14 +0000 (UTC) (envelope-from avg@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745434574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=xvoYRHtXHi7VCSo50aW4U1LhHfo0jpgyLRLpcsvPdjQ=; b=XE9glCeNhQnUy5uoiLnArek+96v69oVx3LWkI468/v9VMmOYAxQOrZuYFNfXx/5BEhGxzb HPdXyDHhKKp67njouZe3pnGbIzvDB5lOXu8uc+xp4Mex3ZH8S4tWPIWjY6zGTq8xWHlidU tkGaqhh1JCCMfgcO1+WqL3x+y58tUueBc5WyVVcZ7ZB3w55eC2y7lZCodpmuMwsoPKRjfW bUIokADXCxXILkQ+oyhcdGsyebRfBQwvXgsKapKJRUsvSRXeTLP8K4j3V1u58HPIrhg7+b yE1hFNyQehG/267QkpOlXtOApVFhCkEcC1N0NQ5frV0ufwsKGP7DgUXEZTqvng== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745434574; a=rsa-sha256; cv=none; b=o8iyTxs8n7tSxq/DfaEZviFn4mUcEvOJA/2L/IzTi/P+IfvKTvbeljouu46V6xPzqrd+ue WomKZSJXtnzltz3K9wJi9n2gHi5sgy4uRvsKK/3/rEDXgnDenxKNh34UvViakRU5Ru00X9 YnRs0dFlkd87J5hlfesJpTEo8Wtd53FIOJRU2qkDX5OH2cVaxRdBy6U7i+4crXlS0ZfRIi 8Ul2D0fpNBg5WtQsGiXTIsJAAF46aUWJi4da5hb4l7td4nH9UEepumXlrw76JRx0Rl6tn8 WF5rQ6MWSP4pf44Xv9ylhFqNwxZLqoLSnUcGZP2cFkcN+Sb9ZeBwNN4LV/oeNg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745434574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=xvoYRHtXHi7VCSo50aW4U1LhHfo0jpgyLRLpcsvPdjQ=; b=YIcYuq3oCNl+M1C+sLjPms69YfGcCvjZFZyDDqYl78ADdfmVQJLZYJ2Tw2BdWlcmcvLTD9 on03lWIZSgDgNGwp3saqWQnVJil2+5ZCFAJ1O8+Dj3MEr95FxofpG4clziY1Ys/hJbBcS2 7pIJ+zkxxde6+n4l00OjzWSzfxVqOt8XpW8Tz7S0DmkvP5Q3zvR7IboaoSGIayOMRQuTQl grSOQdHJd+I21kneLZlkZG4ZvCAvCtiI6pFWKYM2xaRNqU//hLI6aX3Ljdsc0yjZto7WHO 9ACKX7/1246YrK4r0qpFd63HlqLQQEBo/lWafAXeRLa6EYfB7qwUO/gVc8HPWA== Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZjSxV1NgqzngL; Wed, 23 Apr 2025 18:56:14 +0000 (UTC) (envelope-from avg@freebsd.org) Message-ID: Date: Wed, 23 Apr 2025 21:56:12 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Andriy Gapon Subject: Re: RTLD_DEEPBIND question To: Konstantin Belousov Cc: FreeBSD Current References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> Content-Language: en-US Autocrypt: addr=avg@freebsd.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 19/04/2025 13:38, Konstantin Belousov wrote: > And there is the version with the recursive marking by deepbind: I think that this patch would help with my case (haven't tested yet). But I am not sure if it would be "correct". First, as you have rightfully asked, it's not clear that deepbind should be recursive. But even if it should be, there could be some edge case where the same library is a dependency of more than one dlopen-ed object where one dlopen uses RTLD_DEEPBIND and another doesn't. I am not sure how that case should be hadled. BTW, I've been wondering how illumos avoids the problem even though they do not use any special dlopen flags. It turns out that they link almost all system shared libraries with -Bdirect option (which is Solaris/illumos specific). It's somewhat similar to, but different from, -Bsymbolic. https://docs.oracle.com/cd/E23824_01/html/819-0690/aehzq.html#scrolltoc https://docs.oracle.com/cd/E36784_01/html/E36857/gejfe.html I think that on FreeBSD we should use symbol visibility attributes or a symbol map to hide (make local) symbols that are not expected to be interposed or have a high chance to be interposed by accident. IMO, yyparse should definitely get that treatment. I think that approach would be better than magic rtld tricks. Especially because the tricks do not work with the current rtld. I'd rather make a change to libdtrace.so than to rtld. > diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c > index 2346c6eae9f6..9767c8e7016c 100644 > --- a/libexec/rtld-elf/rtld.c > +++ b/libexec/rtld-elf/rtld.c > @@ -3824,27 +3824,26 @@ dlopen_object(const char *name, int fd, Obj_Entry *refobj, int lo_flags, > if ((lo_flags & (RTLD_LO_EARLY | RTLD_LO_IGNSTLS)) == > 0 && > obj->static_tls && !allocate_tls_offset(obj)) { > - _rtld_error("%s: No space available " > - "for static Thread Local Storage", > + _rtld_error( > + "%s: No space available for static Thread Local Storage", > obj->path); > result = -1; > } > if (result != -1) > result = load_needed_objects(obj, > - lo_flags & > - (RTLD_LO_DLOPEN | RTLD_LO_EARLY | > - RTLD_LO_IGNSTLS | RTLD_LO_TRACE)); > + lo_flags & (RTLD_LO_DLOPEN | RTLD_LO_EARLY | > + RTLD_LO_IGNSTLS | RTLD_LO_TRACE | > + RTLD_LO_DEEPBIND)); > init_dag(obj); > ref_dag(obj); > if (result != -1) > result = rtld_verify_versions(&obj->dagmembers); > if (result != -1 && ld_tracing) > goto trace; > - if (result == -1 || > - relocate_object_dag(obj, > - (mode & RTLD_MODEMASK) == RTLD_NOW, &obj_rtld, > - (lo_flags & RTLD_LO_EARLY) ? SYMLOOK_EARLY : 0, > - lockstate) == -1) { > + if (result == -1 || relocate_object_dag(obj, > + (mode & RTLD_MODEMASK) == RTLD_NOW, &obj_rtld, > + (lo_flags & RTLD_LO_EARLY) ? SYMLOOK_EARLY : 0, > + lockstate) == -1) { > dlopen_cleanup(obj, lockstate); > obj = NULL; > } else if (lo_flags & RTLD_LO_EARLY) { > @@ -4679,12 +4678,13 @@ symlook_default(SymLook *req, const Obj_Entry *refobj) > */ > res = symlook_obj(&req1, refobj); > if (res == 0 && (refobj->symbolic || > - ELF_ST_VISIBILITY(req1.sym_out->st_other) == STV_PROTECTED)) { > + ELF_ST_VISIBILITY(req1.sym_out->st_other) == STV_PROTECTED || > + refobj->deepbind)) { > req->sym_out = req1.sym_out; > req->defobj_out = req1.defobj_out; > assert(req->defobj_out != NULL); > } > - if (refobj->symbolic || req->defobj_out != NULL) > + if (refobj->symbolic || req->defobj_out != NULL || refobj->deepbind) > donelist_check(&donelist, refobj); > > if (!refobj->deepbind) -- Andriy Gapon From nobody Wed Apr 23 19:00:15 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZjT2R1KPFz5tlBf for ; Wed, 23 Apr 2025 19:00:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZjT2Q3bWKz3h3l; Wed, 23 Apr 2025 19:00:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 53NJ0GRr099105; Wed, 23 Apr 2025 22:00:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 53NJ0GRr099105 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 53NJ0F8O099104; Wed, 23 Apr 2025 22:00:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Apr 2025 22:00:15 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current Subject: Re: RTLD_DEEPBIND question Message-ID: References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4ZjT2Q3bWKz3h3l X-Spamd-Bar: ---- On Wed, Apr 23, 2025 at 09:09:56PM +0300, Andriy Gapon wrote: > On 19/04/2025 13:29, Konstantin Belousov wrote: > > On Sat, Apr 19, 2025 at 01:25:28PM +0300, Andriy Gapon wrote: > > > On 19/04/2025 12:39, Andriy Gapon wrote: > > > > From a quick look at the code, should we try to resolve the symbol in > > > > refobj itself when it's marked with deepbind? > > > Oh, and it looks like objects loaded under the "deepbind" object (e.g., > > > needed objects) may not be aware that they are in the deepbind sub-tree? > > > > But should they? > > That's a right question. > > I have been reading about RTLD_DEEPBIND and Solaris flags like RTLD_GROUP, > etc at the same time. I guess that's why some things got "fused" in my > mind. So, I started believing that the concept of shared object dependency > groups also applies to RTLD_DEEPBIND. > > But that's not documented to be so, at least, in the documentation that I > could find. There are some in-depth documentation on Solaris run-time > linker and its handling of various options. But for Linux RTLD_DEEPBIND I > could find only manual page references and they only say that deep-binding > applies to to the object being dlopen-ed. > > I am not sure if that's how the option actually works on Linux. > I allow for possibility that the manual pages omit (or, at least, do not > spell out) some details for brevity. > > In any case, I believe that the proposed patch is correct. > But I think that it would not help in my case. > I have: mdb -[dlopen]-> dtrace.so -[needs]-> libdtrace.so. > And it's a symbol in libdtrace.so that gets resolved to mdb instead of > libdtrace.so itself. > The patch would affect how symbols in dtrace.so are resolved if I understand > correctly. Well, it would also affect libdtrace.so, starting the resolution from libdtrace, then falling back to the global list. It might be that RTLD_GROUP is something you need, assuming that for dependencies, resolution should go into the first dso in group. From nobody Thu Apr 24 02:01:49 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZjfNv2SD1z5tGJ3 for ; Thu, 24 Apr 2025 02:02:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZjfNs0V0wz3Dn3 for ; Thu, 24 Apr 2025 02:02:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=UgdEVCTp; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745460123; bh=JiXRX0Yg4R/6XJwmzSTaQUvcz80kRhTAwcPhQttWe4M=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=UgdEVCTpo36HvT1HCmiR8ttYLc933/CW4+antZd2Q8p+8CcUTpfxRZ3/N+1BiDs8hDtbqb18znMrUI4OhpEt9OfOJx2Lrh6QOYvZXbKh151OBv1UsDphNOKTHv7ScqRAWStyDY9TwwAWUVyZYevTzrkVARRfpoE/4grCvD21WjNoDzLkjdQMbysJlTRH0/Dnbqat46jD4tTzCnZQKwfUZk88ja9zlh0jqb9dgrf7fmib/XG/lh3JPiSHOLno/nxp7r1LTMDKRqY6VKLoxGIh7/O6YlvRrH+ACSzze8zF30ek1uLcheHbS/XJo+aAPQzf0PTC+S4qMdMZ49QJI/w8Iw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745460123; bh=U+fpCmwEpoGG6dROBCB2vNyrBQTVinK2qmQZ5EgoEU+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=tMOjaAwT79IEdOwThN2Pn/tw/GDnx0eAfM6ihuDvFg0u6QC6eNv00nSiLV1ocGz7swh8hbZhQP5HPkeCdKDvVsf+ETqB6YCRfIWWcTfNdDv1eJm6LPQYwOJxWR3R17eDLV+AQm8YKHn/n9hWk8wbPDXOT7xJJ24Uxh+qQfx6gesIwvYk8CSyu7E5+jIRPHlGOf3H4gwKB/fdLIey5xM3i15q3zX7M+YxO2RGzPJXe8N4DyhhHRTArhRt8Al1rI/APzWbfvDM2UKVyltDTtluRkGPuoVq+ASThXKdv03MwNE5KtT76B60ypiT8pCSRNaa4NbPcN+qNLydZTtuSUgwMQ== X-YMail-OSG: 5ta1tm4VM1k51oLn2Xo4NISb6etWIXELi6ihTkUjXQeg3oxpxU7aXthEMai7Iuh QNO_IFzLclGjyuSVJAEW5R4C3pCP0eOTN6RYMz9fUTpN7LUq0jK609xSxuf8hwh1AVVWZyZKym7l 6e8k.5IjT9BUv.YeYRuwGQEcE_ntyNxXmVSHrM1vhatC0IsnG_BGJ6rqiKGzCT2HBzhS077cWRG8 ufTWXCps27atIOtcAL5faHxb.fxv3f2rY_NEwJvCeVtedcBqAN415fp_5y8W8tb3JjNmq5zvfnic btlpEO3FA3JpGvguFguhuB7rivE9WS.R4Ua3JdFhOTic83hJVA5js2KCQmVLPmgOTs2XKPQomOJH Qj4JduBLy_NCTeA8m2KyZVCT1pYG1vSDB8_9BSEaM94_of1MLV_sqGqKt9mXz.niTS.A3XA_ANG_ eUtY2CnL.oUfQnOlHvxbuO5KiIscxmDxYPX44.dAIovI0RppUohHc1wCj5gZVlND8C4pw_SQtw7w 3HZB0pZNJqJYP5GJe_D8GLe..xgjpQRwrMrSvo0RXNECVxJUeYu.633reTSsIhIWv87_hWpVLgSC 81DWuB2u82hx.R796HFf770ysjFSHOnOKRLTQYtXij9QFjwq1AR_7HAPYNFo_i4NWfw67CvbAhWc lpzHWwNsw03MgkMbj8pqbf34gk.escS6_XFmusqb9E5l.9xM3nVR0KfrOjdWR7qZePYygB6GuYXW tBU_e7F.mTnxdGloKr.mxpmbPr_Mwj4yxXoeSVmp_JqKgJkfyjzutkM5Wt1Wp0JlzqRBhYaN1Wrq 1wlKJvaEtidaD8NQ37a3HaR7YPhDpTcHa4AvMgQYCiwDsiJ7hPrc.HjN8sUcHYbMuYguPnwEWIlp sCtfv_0E6zPb48uzQZIUaIDPQre66Da895f8LLSg7Ic0mRKzFc_tE3jRk5vPpf2QEPpcKkqk3xNi eiihkUV4RYIiftyIPiV4kcBgW12Nl6_wq.cLyNxmy.KYoXAbOTZNLzIBV8Q0rvSrtEkvxPtWZPVp dZYEhobpttEq.9m8HC6aAyqN3IYiv6H9ZjIKq3kLzQi40IGOcwcB6y0SOtf9_ZGqzBNpqzFbD3ie X0k344t8rrXAQrqgqxQcZJeCQh_rfa5TrIHfxY4nQeB6g3vcFTK34ZLFiHFvVWxtVikzrNV6kaee RCaUOGk6hpSVH1f1Oj0Rd9PjfDCMTQm4lYuCWjSyeV3s5kHT34EyZKEYNUFWHERakrsPyiDm5LGK emAXFelH0j.2ZRKMxdVjZUj.miqVEHgd5Y8x4gLjpUFG16zFmKXrihUAguzEs6zgVCdt1mt3WSGS S8PlF0sPoF_oR3C4pFyD0G84CW0ht44cJVdRL_SHqB6h6xDjUZ2l3fzYmoel1aaArZdgxw6UXjaZ .b0tIYXtwVYxWgRGqUBf6nggDGuHjzvBnrKx91LOnnksBJck2BGd7KuCLgcXAVVgz9OnqxHTLOV3 1F4P9lJ_AC3ea1k4K9SJvSVMpuzixfQILbMI0ihT_ZLgWBGzYqTsZEdTxMhAfzh7mAfqVJ8EcZ0x WorcC21Y.5V4PkcSl2PloLTAddfGhXrrnl8a8pz2gkhsLRlBtY5RLD48H2w042WYdfmVjiko_R1R .2MdwksfEr2GRbKswYyiaEReEiSXKFPnt6rIciTa.jX.04Fl8KtEtdxypBNgQsfikdtlHn2yJL2J Yzg7VUcfprieMBPE_TTSik_DMrs7jmdKVKC7vrK9eB7zaXrJr27dvX.5ZqYvRfvcYykAuwFzf4KW RyLpbnoi.4aHn.cbGhbdsValHThyLNyVLxNvjaRLUAgE1fsrOXbY9rrgc_YGqI4fmUgPGbzTjhts EsPjLNUbOea_hQ2N4.6TUMlKGqcI7kEN9PZ3ilCjLfOQhaQpcgUAu3n7ztiQGp4lFU2y..o.A2iw e_k6m81QdbJL_sLGFeUkcwPiOfPQFCfBbjQ6.0PuiXoeWJWRimSQE4K1LQioQNxgDfgJdEtCupxj Rzu_xe85QaujDBVct9fC8W6LtghWLO2mfPcx.9uYk__rFLAyUg1AwNBBXvcFIbwZHth23IUmbIOE ao9_iUTxDmFWb_I.wB0OwsZw7dT.feiIlPjhTnqIF.blAT8sgExzvmtlG5AgT7lc6N60XHO5P52Z YxWKeBBJjKejXokqKLw_W0j4M6JMnFDksh6zWZn97cbGl5f0okOa_yK0UCruPPIL48lkI5RGs6ch I7Rz28r6bQ1HNSJnJRd_zULePNNDm2FZfM9PnM2zyuNieDJMlIRf6i7OgMbHG4wIeO36uTfcA0Vl u X-Sonic-MF: X-Sonic-ID: 3874b62c-e8cd-4847-92fe-b01f647d500f Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 24 Apr 2025 02:02:03 +0000 Received: by hermes--production-gq1-74d64bb7d7-s6s6l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8ba04b0282b67a8ae8e8774013cfcb8d; Thu, 24 Apr 2025 02:02:00 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: zfs (?) issues? Message-Id: <4330CE6C-510E-426E-A53E-AF09100ACCF0@yahoo.com> Date: Wed, 23 Apr 2025 19:01:49 -0700 To: freebsd-current-freebsd-org111@ketas.si.pri.ee, FreeBSD Current X-Mailer: Apple Mail (2.3826.500.181.1.5) References: <4330CE6C-510E-426E-A53E-AF09100ACCF0.ref@yahoo.com> X-Spamd-Result: default: False [-1.49 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.891]; NEURAL_HAM_SHORT(-0.70)[-0.698]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_LONG(-0.40)[-0.396]; 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)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4ZjfNs0V0wz3Dn3 X-Spamd-Bar: - Sulev-Madis Silber = wrote on Date: Wed, 23 Apr 2025 06:55:06 UTC : >=20 > On April 23, 2025 8:34:36 AM GMT+03:00, Mark Millard = wrote: > >On Apr 22, 2025, at 21:59, Mark Millard wrote: > > > >> Sulev-Madis Silber = wrote on > >> Date: Wed, 23 Apr 2025 04:31:41 UTC : > >>=20 > >> . . . > . . . >=20 > >>=20 > >>=20 > >> If FreeBSD 13.4 can still swapping out process kernel > >> stacks, you may want the likes of /etc/sysctl.conf > >> to have: > >>=20 > >> # > >> # Together this pair avoids swapping out the process kernel stacks. > >> # This avoids processes for interacting with the system from being > >> # hung-up by such. > >> vm.swap_enabled=3D0 > >> vm.swap_idle_enabled=3D0 >=20 > would it be related here? The settings prevent one way of ending up with a normal way to interact with the system failing to do so. There are other means of having such failures. The settings should not lead to problems of themselves, even if the conditions they would avoid never occur for other reasons: The settings should be safe. > >>=20 > >> (I've no clue that that is why you lost control but > >> it may be a possibility.) > >>=20 > >> (main [FreeBSD 15] no longer does such swapping out of any > >> process kernel stacks and the 2 settings have been removed.) > > > >Are you using a file system based SWAP space? Vs. a > >Partition or Slice based SWAP space? >=20 > just 2 gpt partitions Good. Are they encrypted (GELI)? Having the SWAP I/O also involve such processing by FreeBSD does add to the risk of memory management related deadlocks, as I understand anyway. Can testing without the use of GELI to see if that makes a difference be done (if GELI is in use for the SWAP space)? > > > >Quoting: > > > >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048#c7 > > > >on why it should be Partition/Slice based: > > > >QUOTE > >On 2017-Feb-13, at 7:20 PM, Konstantin Belousov wrote > >on the freebsd-arm list: > > > >. . . > > > >swapfile write requires the write request to come through the = filesystem > >write path, which might require the filesystem to allocate more = memory > >and read some data. E.g. it is known that any ZFS write request > >allocates memory, and that write request on large UFS file might = require > >allocating and reading an indirect block buffer to find the block = number > >of the written block, if the indirect block was not yet read. > > > >As result, swapfile swapping is more prone to the trivial and = unavoidable > >deadlocks where the pagedaemon thread, which produces free memory, = needs > >more free memory to make a progress. Swap write on the raw partition = over > >simple partitioning scheme directly over HBA are usually safe, while = e.g. > >zfs over geli over umass is the worst construction. > >END QUOTE > > > >Note the references to ZFS and GELI. Your forum notes reference such. > > > > > >A separate tunable: in case "was killed: failed to reclaim memory" > >is involved but not reported/recorded: in /boot/loader.conf > > > ># > ># Delay when persistent low free RAM leads to > ># Out Of Memory killing of processes: > >vm.pageout_oom_seq=3D120 >=20 > helpful here? This tunable contributes to how long before one type of OOM activity starts. Larger values lead to larger times. The default is 12. More than 120 can be used. The figure is good for allowing known temporary conditions time to complete so that they do not lead to OOM activity. It used to be that FreeBSD reported "out of swap" inaccurately for some other conditions where it now produces more accurate/specific messages. There is still a "out of swap" catchall that can be inaccurate. The setting should not lead to problems of itself. >=20 > > > > > > > >Separate question: why did some forum top runs show > >qemu-system-arm threads? That could be a significant > >competition for RAM+SWAP. >=20 > it's small vm yes. but it behaves well. part of it gets swapped out. = then back in, so on Just because something appears to behave well considered in isolation, does not classify if it is contributing to system level problems. In a small RAM context, top showed 600+ MiBytes of resident (probably active?) memory for qemu-system-arm, if I remember right. In other words, possibly 600+ MiBytes not normally available to to other activities that compete for RAM, at elast for a time. > it's all funny, i might be using more things in that machine than i = have ram for. but it just gets swapped out. swapping it back in causes = delay in that thing that needs that. like always It also leads to delays in whatever had pages written out to make room for what was to be paged in, time on overhead instead of on more-directly productive work. > i still think git does something here. I've no way to collect evidence relative to such issues. As stands, I've no way to use these sorts of notes: I cannot even produce a setup known to be analogous and then test it for if I end up with the problem reproduced. (Apparently, that context would include use of qemu-system-arm in order to be analogous.) Your context may be too complicated to reasonably set up something analogous. > if i don't touch git, everything is absolutely perfect. why git? if i = restrain it from config, it seems to not cause issues. except maybe they = are hidden now >=20 > whatever happens, it happens in memory that is impossible to swap out = or is not preferred to swap out >=20 > git is not swapping and then being killed. that's not how it will = affect the system. i think i helps zfs to take all memory and either = throw unusual errors, like that single case. or just cause total = exhaustion >=20 > what's fun is it never appears elsewhere. everything else seems to = work as one would expect it to work when low rammed I've no idea how to put that description to any use or to test confirm or deny any of the hypotheses involved. > > > > > >=3D=3D=3D > >Mark Millard > >marklmi at yahoo.com > > > > >=20 > p.s: >=20 > i also found >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231457 >=20 > where people experince (maybe) similar issues many years ago >=20 > is it active issue still? FreeBSD 11.* was a fair time ago and various issues have been addressed since then. It is not clear how that bugzilla could be of use. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 24 05:56:44 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zjlbg3v94z5tZ3G for ; Thu, 24 Apr 2025 05:56:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zjlbg2M1Hz3fnF; Thu, 24 Apr 2025 05:56:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745474207; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=fBMDQHQbtBligR5jKUotrI6FT/cUxbD7uh0tZ4bduGs=; b=yPPWQX41GTMtx+XLKx7uTNPPqTyzo6SmsmVibGxsslx5n7ujkOUUa4Sq7V44HEVLggeyGe SR1Xg8WFADsxcRgbnTFXVwLokHhgrlqLQnmS+9R+pLcW3l+X3c3k9aB5VgLgMCRVoyUqE5 k/qa4aHi0LWdtkYbyJf2SunFm/SOF+/LfonJhkZlj5VBkCSQr6LNQ2DtOSg+MX34WLuQ89 ThTCV3XswtXt0LDBXJnSu85oerKJBsqb842FvMZoxnAgSXVUJ+Pgj/OP/tgTrjZkNkeFwl eY9ARaqlQ7rVeCttKnJhTbQqHv5R/T+40L/3HJIzNQtV4OCjr3qA+nO7C58+2Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745474207; a=rsa-sha256; cv=none; b=EF0KEkzS2Z6XcJfhq3hDOFuWXqPoM7bzTiXybaFYfu3QkInt327fhKAJXY8v72m39N4ZFK 3MEq4LbSXdh6csZ6guc9QSirvfJoIVb2TuhrRN1gLNvfzUmySNROgbjKOq9AdQXqJbgjA0 Ejk0BN8SopyINXRBmZJG0Ns9cQW5yjwomwuKdfSl7u0KLysiRYDXJNstX9gznoYANvrTCG cH+uvPYU7czztDscswySAUEw9mg6W73pXU20C2ritGDRNYv7jD4rDKP5jIN64zUwds6d7i 4bKD8uyDnzDFpvQv2IWX5TbiJm16Zf09ieVhdj4athPLrrFhyWybKZNrFqKpeQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745474207; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=fBMDQHQbtBligR5jKUotrI6FT/cUxbD7uh0tZ4bduGs=; b=c3Tiu9/QW4alFSavpNJz+vNjo61b6gqVt9wXg3FZdIChg/o7muglk8dum3qXGnEsdMIZO9 7HAqD7SCeT9CdxzxYKJl2a3LyYEY/QEjdpk5KASauNJzJdtGS/KCEKyl6m07kBqYYDzvEh 2BP80WMG/DV4OfE4rv15REM6q9HxA94JumMIbspEw6uDFMfq+reOER39S9jqIc4hDK8do1 xlwSdma4/K9NuYTbqO0oZlqD0Xa+VBOXVPzY7wAlhGGRo0yreBGIVEw24sbCX1KFIwWBPV V8SYKhXIkSiIcsPJqaFqnXyt/pS56/Xpb0jIBfQ2/13BJmPV0ll4K/30Pa8O/A== Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zjlbf4D2nz11rF; Thu, 24 Apr 2025 05:56:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <59db8ace-770f-4f73-976f-411f6de0885a@FreeBSD.org> Date: Thu, 24 Apr 2025 08:56:44 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RTLD_DEEPBIND question From: Andriy Gapon To: Konstantin Belousov Cc: FreeBSD Current , Mark Johnston References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> Content-Language: en-US Autocrypt: addr=avg@FreeBSD.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 23/04/2025 21:56, Andriy Gapon wrote: > BTW, I've been wondering how illumos avoids the problem even though they do not > use any special dlopen flags. > It turns out that they link almost all system shared libraries with -Bdirect > option (which is Solaris/illumos specific). > It's somewhat similar to, but different from, -Bsymbolic. > https://docs.oracle.com/cd/E23824_01/html/819-0690/aehzq.html#scrolltoc > https://docs.oracle.com/cd/E36784_01/html/E36857/gejfe.html Oh, and it looks like there is an even better explanation for illumos. There is a version map file for libdtrace which explicitly lists API functions and makes everything else local. https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libdtrace/common/mapfile-vers I wonder why we didn't do the same when porting. Maybe we should do that now? > I think that on FreeBSD we should use symbol visibility attributes or a symbol > map to hide (make local) symbols that are not expected to be interposed or have > a high chance to be interposed by accident. > > IMO, yyparse should definitely get that treatment. > > I think that approach would be better than magic rtld tricks. > Especially because the tricks do not work with the current rtld. > I'd rather make a change to libdtrace.so than to rtld. This, while not as nice as the illumos solution, fixes my specific issue: diff --git a/cddl/lib/libdtrace/Makefile b/cddl/lib/libdtrace/Makefile index d086fffb07bc..58054d129b49 100644 --- a/cddl/lib/libdtrace/Makefile +++ b/cddl/lib/libdtrace/Makefile @@ -146,7 +146,8 @@ CFLAGS+= -fsanitize=address -fsanitize=undefined LDFLAGS+= -fsanitize=address -fsanitize=undefined .endif -LIBADD= ctf elf proc pthread rtld_db xo +VERSION_MAP= ${.CURDIR}/Symbol.map +LIBADD= ctf elf proc pthread rtld_db xo CLEANFILES= dt_errtags.c dt_names.c diff --git a/cddl/lib/libdtrace/Symbol.map b/cddl/lib/libdtrace/Symbol.map new file mode 100644 index 000000000000..89ee9de65209 --- /dev/null +++ b/cddl/lib/libdtrace/Symbol.map @@ -0,0 +1,4 @@ +{ + local: + yy*; +}; -- Andriy Gapon From nobody Thu Apr 24 14:04: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 4ZjyR54d5Zz5tLYS for ; Thu, 24 Apr 2025 14:05:05 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from fhigh-b1-smtp.messagingengine.com (fhigh-b1-smtp.messagingengine.com [202.12.124.152]) (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 4ZjyR40592z3G7K; Thu, 24 Apr 2025 14:05:03 +0000 (UTC) (envelope-from dch@skunkwerks.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm1 header.b=rpwYHwF9; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="i x6/MN7"; dmarc=pass (policy=reject) header.from=skunkwerks.at; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 202.12.124.152 as permitted sender) smtp.mailfrom=dch@skunkwerks.at Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id C23D22540170; Thu, 24 Apr 2025 10:05:01 -0400 (EDT) Received: from phl-imap-16 ([10.202.2.88]) by phl-compute-02.internal (MEProxy); Thu, 24 Apr 2025 10:05:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm1; t=1745503501; x=1745589901; bh=z+NHtrMz79t7HGE1WyvWIbYn6gLQvrPy N8A+VXXwo+M=; b=rpwYHwF9rZTfCiRskhqiJl1rs77577DzMKqyTFq7NZq5D/Il nGnqu81h/yvnoaNncasVh6WYP9uS8fbRrJA8zcOM99RKJ1uEBmTR6VzYxECLLGDP nTLiMmXYI0+YTGxXXRIErau9qIns678iMFXDWbxwrWr2QjJ3UcimGhJQRJyXNqgN UTlRWxguiBnrBLDHOOT6+VStffQU1PDtX85eWhvcK7YcpBjp4EiHv0+kfy1PXkh9 uqf+j2564wU5chO16Uml+Qdv6RTvDp6b5iXeruxKIvRDLCaQa51ODwfwqaBeiyk3 rfJ4YXz/ZBDORolE9FF9ot0QZe08zjz2USDIMQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1745503501; x= 1745589901; bh=z+NHtrMz79t7HGE1WyvWIbYn6gLQvrPyN8A+VXXwo+M=; b=i x6/MN7O6q1PxprzCDuGr/CrO3/NbOLHE7ijPNtPInoYrslyRKnmhGcttevjSp96T 5HMUiBEQmiLKdvS0tt7K1+19kehGDTolETUUjeUaOCDfG8HLCF94AjaUj+3gn9iW pVk3+mHF56jnvv0ZwiwDv/7BVrzrSga+GE9VxuZ8IZPQubH9vcUiODlQDEYWcZto X1fIP2XsWx2SEPjUdn1SqOQvC9DEWsmRd1IaTDO4eBwkn+v3OXNNGweS8T/N98Da M/XzLv3G/eXYmwR8568o8qi1TQDtV/r/YTutl/JIdnCfLkh1ddSJ2NuJj7D8hPPU Wj7u9bsbAY3niSsIs0Czg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvgeelieeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvvefkjghfufgtgfesthhqredtredtjeenucfhrhhomhepfdffrghvvgcuvehothht lhgvhhhusggvrhdfuceouggthhesshhkuhhnkhifvghrkhhsrdgrtheqnecuggftrfgrth htvghrnhepteelffevhfetuedvtedutdekgfejveduvefhleehueefffehveffgfehkeei hfeinecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrdgr thdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepih hmphessghsughimhhprdgtohhmpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghn thesfhhrvggvsghsugdrohhrghdprhgtphhtthhopehglhgvsghiuhhssehfrhgvvggssh gurdhorhhg X-ME-Proxy: Feedback-ID: ic0e84090:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id C4D932CC006E; Thu, 24 Apr 2025 10:05:00 -0400 (EDT) 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: T7d8fb190958b0cc3 Date: Thu, 24 Apr 2025 14:04:39 +0000 From: "Dave Cottlehuber" To: "Warner Losh" , "Gleb Smirnoff" Cc: freebsd-current Message-Id: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> In-Reply-To: References: Subject: Re: April 2025 stabilization week Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.05 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.97)[-0.968]; DMARC_POLICY_ALLOW(-0.50)[skunkwerks.at,reject]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm1,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.152:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FREEFALL_USER(0.00)[dch]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4ZjyR40592z3G7K X-Spamd-Bar: ---- On Mon, 21 Apr 2025, at 14:22, Warner Losh wrote: > Please note: Gleb is on vacation this week, so I'll be coordinating > stab-week this time. Please be sure to cc me on any problems you > encounter. > > Warner > > On Mon, Apr 21, 2025 at 2:00=E2=80=AFAM Gleb Smirnoff wrote: >> >> Hi FreeBSD/main users & developers: >> >> This is an automated email to inform you that the April 2025 stabiliz= ation week >> started with FreeBSD/main at main-n276625-d4763484f911, which was tag= ged as >> main-stabweek-2025-Apr. >> >> Those who want to participate in the stabilization week are encourage= d to >> update to the above revision/tag and test their systems. thanks! This issue actually came up last month but I had no time to investigate then, details https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D286045 panic on startup: Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 02 fault virtual address =3D 0x0 fault code =3D supervisor read instruction, page not present instruction pointer =3D 0x20:0x0 stack pointer =3D 0x28:0xfffffe00d89c7e38 frame pointer =3D 0x28:0xfffffe00d89c7e60 code segment =3D base rx0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (irq51: iichid0) rdi: 0000000000000000 rsi: fffff8002b21bd40 rdx: 000000000000003e rcx: 0000000000000700 r8: 0000000000000000 r9: 0000000000000100 rax: 0000000000000001 rbx: fffff800015a7000 rbp: fffffe00d89bde50 r10: 0000000000000000 r11: 000000000000003e r12: fffff800012ad600 r13: fffff80031e5b200 r14: fffff8002b480c00 r15: fffff800084a1000 trap number =3D 12 panic: page fault cpuid =3D 1 time =3D 1745502499 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame Bxfffffe00d8= 9bdb60 vpanic() at vpanic+0x136/frame 0xfffffe00d89bdc90 panic() at panic+0x43/frame 0xfffffe00d89bdcf0 trap_pfault() at trap_pfault+0x48d/frame 0xfffffe00d89bdd60 calltrap() at calltrap+0x8/frame 0xfffffe00d89bdd60 --- trap Oxc, rip =3D 0, rsp =3D Bxfffffe00d89bde38, rbp =3D 0xfffffe00d= 89bde60 =E2=80=94-- ??() at 0/frame 0xfffffe00d89bde60 ithread_loop() at ithread_loop+0x266/frame 0xfffffe00d89bdef0 fork_exit() at fork_exit+0x82/frame 0xfffffe00d89bdf30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00d89bdf30 --- trap Oxc, rip =3D 0x303bd21da54a, rsp =3D 0x303bdb553f48, rbp =3D 0x= 303bdb553 f58 KDB: enter: panic I thread pid 12 tid 100281 ] Stopped at kdb_enter+0x33: movq $0,0x104fc22(%rip) db > from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D286045 Darius suggested guarding sc->intr_handler, and with that https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D259480&action=3Ddi= ff I can boot successfully again: THREAD_SLEEPING_OK(); error =3D iichid_cmd_read(sc, sc->intr_buf, sc->intr_bufsize, &actual); THREAD_NO_SLEEPING(); if (error =3D=3D 0) { if (sc->power_on) { if (actual !=3D 0) L#635 ********** sc->intr_handler(sc->intr_ctx, sc->intr_buf, actual); else DPRINTF(sc, "no data received\n"); } } else DPRINTF(sc, "read error occurred: %d\n", error); iicbus_release_bus(parent, sc->dev); } I have no idea why/how we get to here with null sc->intr_handler though. A+ Dave From nobody Thu Apr 24 14:10:24 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZjyYg4KKLz5tM6F for ; Thu, 24 Apr 2025 14:10:47 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from fout-b2-smtp.messagingengine.com (fout-b2-smtp.messagingengine.com [202.12.124.145]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZjyYf4RZFz3KG0; Thu, 24 Apr 2025 14:10:46 +0000 (UTC) (envelope-from dch@skunkwerks.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm1 header.b=vxMj8rSH; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="G KfqPfi"; dmarc=pass (policy=reject) header.from=skunkwerks.at; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 202.12.124.145 as permitted sender) smtp.mailfrom=dch@skunkwerks.at Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id 0E33411400ED; Thu, 24 Apr 2025 10:10:45 -0400 (EDT) Received: from phl-imap-16 ([10.202.2.88]) by phl-compute-02.internal (MEProxy); Thu, 24 Apr 2025 10:10:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm1; t=1745503844; x=1745590244; bh=n0kzCJZvxUKIvE2Nu0ba+lZwtU3eWmZM LQSVz41F67k=; b=vxMj8rSHFRAcBa6rzUzh8zMGIrrd4mNWnSDKND71E5Qhr2US 7GEkr5LP+meRJjDbXWDfDbW/1n11NVORLfwCZsnx96KLBguRUOwMU4LeB6Bb5EkP JICmzbrXtjBmD80+XG1fOpo0mOqIEbQ328gWccUr65nmXv3oKKIwokvn7me6O4UZ ThwPd6pWbZm30EYqn/4oTKgPsOYLby9OZ3vqvxhKXIfq1j5ydzF0IkN4BD8lgbXX reBsUfzfDZRXhChqSkY2sgYoyoKAwEa/cDB6k37TFIUdXGH33y3OoD3oY4LTduNK dPM09Ep4HaWriNa77zM/JGc+bu65kUij6VbVsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1745503844; x= 1745590244; bh=n0kzCJZvxUKIvE2Nu0ba+lZwtU3eWmZMLQSVz41F67k=; b=G KfqPfiAujwVPC82W/l68/MmDBOVsKgqF3ihNWP4UP2RKUNrc7CnCgtnPHEeuN9qM EAvMt8cYB40ZaM1fkhOrvV+RIRZIiLBsDN2Mlc1E3A+hHQeuxtqwtbdau32Wh941 wcfopaJzCjT7G4t/7qzhg+jqozjO0FLbf6Q+7Tnz13ooBxeDR3Iu1RH5pl4oMbDQ PckE0N10JIU4yPu1Be0NoiTUuIVwyDWJlFoH7uCWoZoB6C5FoQYER8RJULgL2yhb +kfTeU6yaoGC0YEcwtbGnpb1t/FGeNeO+8UwL7qS3+UZZ+MJ4P3FayiGfTEq2OZ5 HL54tXLf3c8zFJZbYZ5BA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvgeelieejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvvefkjghfufgtgfesthejredtredttdenucfhrhhomhepfdffrghvvgcuvehothht lhgvhhhusggvrhdfuceouggthhesshhkuhhnkhifvghrkhhsrdgrtheqnecuggftrfgrth htvghrnhepieffhfdujeelieekueehgfeigeekleeljeeigefgudeuheetgfdtgeffieev uedvnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrdgr thdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepih hmphessghsughimhhprdgtohhmpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghn thesfhhrvggvsghsugdrohhrghdprhgtphhtthhopehglhgvsghiuhhssehfrhgvvggssh gurdhorhhg X-ME-Proxy: Feedback-ID: ic0e84090:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id A837C2CC006A; Thu, 24 Apr 2025 10:10:44 -0400 (EDT) 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: T7d8fb190958b0cc3 Date: Thu, 24 Apr 2025 14:10:24 +0000 From: "Dave Cottlehuber" To: "Warner Losh" , "Gleb Smirnoff" Cc: freebsd-current Message-Id: In-Reply-To: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> References: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> Subject: Re: April 2025 stabilization week Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-2.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[skunkwerks.at,reject]; R_SPF_ALLOW(-0.20)[+ip4:202.12.124.128/27:c]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm1,messagingengine.com:s=fm3]; NEURAL_SPAM_SHORT(0.11)[0.111]; RCVD_IN_DNSWL_LOW(-0.10)[202.12.124.145:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[dch]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4ZjyYf4RZFz3KG0 X-Spamd-Bar: -- On Thu, 24 Apr 2025, at 14:04, Dave Cottlehuber wrote: > On Mon, 21 Apr 2025, at 14:22, Warner Losh wrote: >> Please note: Gleb is on vacation this week, so I'll be coordinating >> stab-week this time. Please be sure to cc me on any problems you >> encounter. > from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286045 Darius > suggested guarding sc->intr_handler, and with that > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=259480&action=diff > I can boot successfully again: > > THREAD_SLEEPING_OK(); > error = iichid_cmd_read(sc, sc->intr_buf, sc->intr_bufsize, &actual); > THREAD_NO_SLEEPING(); > if (error == 0) { > if (sc->power_on) { > if (actual != 0) > L#635 ********** sc->intr_handler(sc->intr_ctx, sc->intr_buf, > actual); > else > DPRINTF(sc, "no data received\n"); > } > } else > DPRINTF(sc, "read error occurred: %d\n", error); > > iicbus_release_bus(parent, sc->dev); > } > > I have no idea why/how we get to here with null sc->intr_handler though. > > A+ > Dave workaround below: >From 2f8ea6473c2ece8387691a950b8f9e9ec7b8f8bf Mon Sep 17 00:00:00 2001 From: Dave Cottlehuber Date: Fri, 11 Apr 2025 22:24:07 +0000 Subject: [PATCH] iichid: panic --- sys/dev/iicbus/iichid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sys/dev/iicbus/iichid.c b/sys/dev/iicbus/iichid.c index b86858791a4d5c4ef790ce4ca0761a2af85a5142..88706ecf460c6f3ca6e8e317a28df220bdad0b97 100644 --- a/sys/dev/iicbus/iichid.c +++ b/sys/dev/iicbus/iichid.c @@ -631,7 +631,7 @@ iichid_intr(void *context) THREAD_NO_SLEEPING(); if (error == 0) { if (sc->power_on) { - if (actual != 0) + if ((actual != 0) && (sc->intr_handler != NULL)) sc->intr_handler(sc->intr_ctx, sc->intr_buf, actual); else From nobody Thu Apr 24 17: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 4Zk3172JT6z5tZtm for ; Thu, 24 Apr 2025 17:31:23 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zk3170mjwz3xTt; Thu, 24 Apr 2025 17:31:23 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745515883; 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=lh/TKA/hhYwfE9SAQvKSytE94TMc6AYMMCb2q6zDlQw=; b=ZMlXxjLOGlHWSXYm1RHfiaCyeWqs0aK+iSArWt20EvHWrW+YR+69aTsdL7tfP1KcTR8xpu cs5Gn3p8nGSmOF/i4OCwBXlId7iLoy2yk6mJaxrbRcGgyNt0Adjzk3p+JfqKuWbQK0uCbI PZlSmcsiizGOLuNQBmYOsuXwvK3SsCfqhcVyefdStixWuEcyuGcI9eVrVbF27cu8J8mVy8 gf0KGLcV67tAJnDIpKpz8pP/q2HJuj1g9FZj4CWNh7ZcC4NYWr43xhMogHWpO+G7hLYn+G 6SLIQTszmWKdtcCN8HJoCdr8UCszbJUvNy+UC0idnvHG0qY7mcgEqWWqybQ2sA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745515883; a=rsa-sha256; cv=none; b=PKvxqM4NHMbWbLlGdTvp98kb1LlvIHtyUBVIfN8OualtE5Jz2wudxAFDzdmM00ZtyoRh7F VRYYf1xtrRJ2vt9Yo+RgalhminEG4XcxsWDZtM2WdbpmnrWlaD2lwa+EL7hLyeikmAFYNS fonJwS2mVGdpxOS92CS88FoWhj0Ix0qzF69/vYHmPHWPR8E+aGzn+ed0fH5maJaVwM/R9o yVnyaumnSkawldu6csljGgOk+0KlQCNxiNJWVCJaBygR9hY1CmZsf0hC4iFsImcm9Q9yDn 3efqMYf/XnKrdz73LIhoR2WFQKQscD5JB2rCuas/r/MoriKQZxYDJMfnXGekaw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745515883; 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=lh/TKA/hhYwfE9SAQvKSytE94TMc6AYMMCb2q6zDlQw=; b=IsTfjsmlDJg7UZGSbGvAquc08Wh6VdhtFK1FYWwG2D8OK5kME/ljoHMh3+pqGr6nKqletA S9a0DUs9moOE5IAJmcMEVmB4FWxBrj317u0v0Bck+3NYsWzn2DcUSo1Qv52jPsn00JbuJ1 9GBmg9c0Uro5fLDH1kUh1WqQZmyBdbsflggJgc+CT4IbfJMmiT52szDWR6suGJzI+wMISG pxi0uu5bh3zaS2ee9XHYHhNboCS/R4Lftz5LY3vt4C0VxNP9BouJM4XT31V9TwmlmV6h1D kk1wU1GXJFptNtqjDLqY1Xy7QNcGAkNnjCXL20p/21FLrTahwx4IEKLp8PrBxw== 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 4Zk3164BrRz1HPY; Thu, 24 Apr 2025 17:31:22 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Thu, 24 Apr 2025 10:31:20 -0700 From: Gleb Smirnoff To: Dave Cottlehuber Cc: Warner Losh , freebsd-current Subject: Re: April 2025 stabilization week Message-ID: References: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> On Thu, Apr 24, 2025 at 02:04:39PM +0000, Dave Cottlehuber wrote: D> On Mon, 21 Apr 2025, at 14:22, Warner Losh wrote: D> > Please note: Gleb is on vacation this week, so I'll be coordinating D> > stab-week this time. Please be sure to cc me on any problems you D> > encounter. D> > D> > Warner D> > D> > On Mon, Apr 21, 2025 at 2:00 AM Gleb Smirnoff wrote: D> >> D> >> Hi FreeBSD/main users & developers: D> >> D> >> This is an automated email to inform you that the April 2025 stabilization week D> >> started with FreeBSD/main at main-n276625-d4763484f911, which was tagged as D> >> main-stabweek-2025-Apr. D> >> D> >> Those who want to participate in the stabilization week are encouraged to D> >> update to the above revision/tag and test their systems. D> D> thanks! D> D> This issue actually came up last month but I had no time to investigate D> then, details https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286045 Is this regression since last stabweek or from an earlier point? -- Gleb Smirnoff From nobody Thu Apr 24 17:48: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 4Zk3Pd254Lz5tbyT for ; Thu, 24 Apr 2025 17:49:09 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from fhigh-b3-smtp.messagingengine.com (fhigh-b3-smtp.messagingengine.com [202.12.124.154]) (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 4Zk3Pc5fmRz3D9r; Thu, 24 Apr 2025 17:49:08 +0000 (UTC) (envelope-from dch@skunkwerks.at) Authentication-Results: mx1.freebsd.org; none Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id 6EDD32540217; Thu, 24 Apr 2025 13:49:07 -0400 (EDT) Received: from phl-imap-16 ([10.202.2.88]) by phl-compute-02.internal (MEProxy); Thu, 24 Apr 2025 13:49:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm1; t=1745516947; x=1745603347; bh=0dfrVf107Q9W80HcPU9yrH5BGYdyWqyY NjT/DhMDVa4=; b=q6cen+6JsBWanaEUlrriZM/6/MOXpCzTV6c7DYqWRJzKD2Qq Gv64A9mt4nGuwo0JmuURTx5FrWOz5b9Fneti1I8qyPIFr48JU3UPuDSD76DtOkTM MxdMVOXkbn/wVJ4jUKaGriMnF0LueGlacvzPsLdYBpN1I6T8xag9xFwFPRiCmUr1 aruBYhMrHFYU4MCY0hv1lCcy5a9rE6fwO9Wg8WnUWqIN2zC0ZKUh2bfILIrXASSQ dArKHGF0c9AiFQOBaMnIzbnEHVTGzQ+A8EQi96BZFSEVOXi8S8Lov1p9vFjAfpJk pIDCgLqHgdf6N02CFsRUsXWjTnYDwAKHLJ0M2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1745516947; x= 1745603347; bh=0dfrVf107Q9W80HcPU9yrH5BGYdyWqyYNjT/DhMDVa4=; b=m gdmKQTHkzGga6TdEPBqVuMlKfSklP1IDEAaEsCJH2aX6lFoptjkI53E+ZS+pVCD+ PzvwuQO+iXH/gLheMFwDWgjs6LfEhxD5eJwBzcitBn3BE87U7R4LFTIEP9oCrLbR RGe5DVE0ujCHpaJYn6ZTBqKfLisTWwmtgsBdDHAeVE1nk1vipPqyXnU37dhGQbwt C5v/R30Oydd6Y5Xqn1MzkYJzI6orXr5fLgkXKjNEE/m2rSsYeQ+g/ebIik8/BM/7 /2outP9JFoca/F8mKPAKuMWuaG1yIGn7tiKf1FB6mxDiXwOKtNytHEojgqNxWrfI EYt7CkYruBX9q5GCwGhbA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvhedtudduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvvefkjghfufgtgfesthejredtredttdenucfhrhhomhepfdffrghvvgcuvehothht lhgvhhhusggvrhdfuceouggthhesshhkuhhnkhifvghrkhhsrdgrtheqnecuggftrfgrth htvghrnhepieffhfdujeelieekueehgfeigeekleeljeeigefgudeuheetgfdtgeffieev uedvnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrdgr thdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepih hmphessghsughimhhprdgtohhmpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghn thesfhhrvggvsghsugdrohhrghdprhgtphhtthhopehglhgvsghiuhhssehfrhgvvggssh gurdhorhhg X-ME-Proxy: Feedback-ID: ic0e84090:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id CB8322CC006A; Thu, 24 Apr 2025 13:49:06 -0400 (EDT) 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: T7d8fb190958b0cc3 Date: Thu, 24 Apr 2025 17:48:46 +0000 From: "Dave Cottlehuber" To: "Gleb Smirnoff" Cc: "Warner Losh" , freebsd-current Message-Id: <4aad4a70-a953-458b-ac37-675b6901f28c@app.fastmail.com> In-Reply-To: References: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> Subject: Re: April 2025 stabilization week Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Queue-Id: 4Zk3Pc5fmRz3D9r X-Spamd-Bar: ---- On Thu, 24 Apr 2025, at 17:31, Gleb Smirnoff wrote: > D> This issue actually came up last month but I had no time to > investigate > D> then, details > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286045 > > Is this regression since last stabweek or from an earlier point? Hi Gleb Just since March stabweek. A+ Dave From nobody Thu Apr 24 18:46:55 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zk4hL0txXz5tfcS for ; Thu, 24 Apr 2025 18:46:58 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zk4hK6xHTz3lm8; Thu, 24 Apr 2025 18:46:57 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745520418; 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=o/P+dk2LUZLT+HzaSCkhwxur0wlhUGi8Odib2QS7tqM=; b=loBqdM3wR8UkILboDhpO5dfHzamFJiA9L4tuxt91HnAeKIgSmoo7I1dHUGRf6lDHahsJKC 2uqU8uUCHdlY7g8EWkyejDP+peUA+gtPF8KRtCDosTIxFQDQOZe10np1xZIqZBjZDX4vKk avdIpFhAYhOUOk/9g5N8KSvkn3Y7puKUDe0os65pbM9WkdLsvXmhyfVbrnm8ckWesAgoUV 1cZtmv7UW6tIuVv5dkhCYJ3mUffQEhIRjX6Bk0NMH+/dLwOFSiqaRCusABoCFOWnMRQZcO 5mdt+c/SFhsjmj49keDFU6mGnwP+2R263R/t5APqpz3v1PRKVdVHvAfl5FTftA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745520418; a=rsa-sha256; cv=none; b=Y6nQX6mkXXzjMwLDqSKvqVOj/hdwqmMZUmzfWcxhBeO+Dz7XnhY5PD9+ChOFPaDBSJ4G5H SmiLKc+DRnFGU8srZ5xCasPzyWN60ySXcDnGjPQIP7x51wemNuKvsfsFRhWfVO966GPqxK gkXZqYl25eEibrvGG51ZpxYhU+0FZmt6OcxN5FoURB0ufCaNkC22iZ1VGXrJlbRL2ekQ4X FwRPtzGwJrzPIJqWAZnhXsrPS0GVwLKgjS3AFJfWBywAT9CevyXssgHbJs9kxPn0IbrjmZ USMyR6DjnRMrAL68/ofNjZfd7uEUnGh9wHZzTu5+jn4YZAO+phi6cINWJpClYg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745520418; 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=o/P+dk2LUZLT+HzaSCkhwxur0wlhUGi8Odib2QS7tqM=; b=T3yz9DUgdFG8CpSlFbfkRTWQlejH2G4GOgOw4rPiHVS3rjsq5y9nhnEQ8OcIzXV1YQ0UJC VMXtenH+MU/OV952DdpphOe5SPvcv5K6zqL15mXUQdIIcFBAtEloeV+ZdRVEmduQGMRyzk 2mddle0D6bPdGAC6rxvUQ1ecS6bF1sXm879t/0W8biFQbSbortcUHG1AN4tEFbH8gma6sx m65zI7pYKELZXyy3orz39ccfKU+zaIj6mCx1dQPsuLSNC7FGGGCgdqCHWQzTJRAneGin9O Mjm51UGkmcDxT5wk9l7mpQe8Z380cevZ4Tp7ljopirkXykUWM8Fk6EZ1Ym4bjQ== 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 4Zk4hK31zNz1Hmq; Thu, 24 Apr 2025 18:46:57 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Thu, 24 Apr 2025 11:46:55 -0700 From: Gleb Smirnoff To: Dave Cottlehuber Cc: Warner Losh , freebsd-current Subject: Re: April 2025 stabilization week Message-ID: References: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> <4aad4a70-a953-458b-ac37-675b6901f28c@app.fastmail.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4aad4a70-a953-458b-ac37-675b6901f28c@app.fastmail.com> On Thu, Apr 24, 2025 at 05:48:46PM +0000, Dave Cottlehuber wrote: D> On Thu, 24 Apr 2025, at 17:31, Gleb Smirnoff wrote: D> > D> This issue actually came up last month but I had no time to D> > investigate D> > D> then, details D> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286045 D> > D> > Is this regression since last stabweek or from an earlier point? D> D> Just since March stabweek. There were no changes to the driver :( Any chance you can make a bisect? -- Gleb Smirnoff From nobody Thu Apr 24 19:00: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 4Zk4zv5WKmz5tgMc for ; Thu, 24 Apr 2025 19:00:27 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zk4zv4f6fz3swj; Thu, 24 Apr 2025 19:00:27 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745521227; 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=7Qyd0yPoNliLrwhIfMDnqC5MBz1ivADk3IhG9BiOQs8=; b=EsBPnTCYNS2Y38NCSFyDfcQXARbT0ozXpH0ZPltfqvOomi/pzLf8qxxsN9yvnSKbX4RJv0 mEcEF52iXgtkktbXuXIv4K+l+jWyrBcOHtSaVSBkt6KJBreaaZXMWmyXaV7V4Z5YY0k2so CkYBX547OPWa6Rpq2Tnvh/5DxvGu0mhyni6rbFOAWQYdpYkMhssMSXxKHPza8HS3GkkVJt AEvk3KxUg9eEBHE9HUdKrnFsqQvHt9ytIAwUMcBUCb/gd/7w7HkCEm8dFKFz4DBjCnjHza POW4MD3gko/83t+jLd/G1Qg4q7TPY4WKDhNMNI0Bdu9gwCbthRBGEFCdEB07Ow== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745521227; a=rsa-sha256; cv=none; b=lBS3K8+soA4heETSb0BzKalGkrekd1Pot55hta+bWdzgJV8PKhGw3nm9fihvOT/2tBMsSQ qcezCch6WPkMvDCDRf4oo3OsAqpNvH0HWj8igICdM5dTphEjm5V5zXsRZHWXGHT6/0snEn wiqkFgt8tpzi2M/ebduXj+8iqsP4qAeTOCcklGyB0q69kFtGunN7atDjEBQnVmdM4FkmjN 1Y+7/umKVF8bYbs6gAwr/vqyqdriG5mfQDCfYUgb+Ui3gdBgGPANdsKPOEoer0ZGUeT4MQ qOK68Z+dEfKq1LqCWx3vFgqYjBPQLskpx3/Ub6u/ZVTJaSK0KtcR9RNQw0sqbA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745521227; 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=7Qyd0yPoNliLrwhIfMDnqC5MBz1ivADk3IhG9BiOQs8=; b=kxd8nat1+CCNsX15cqOYXB6G7lvM3NaLR55b5u/+MKxeleyq6Tnom0UJR8LH6X+iuSzM5T Glai1ATu4o6/aGtBmilO6UG9tz1M64pzCRXJUEh2WypF73hcnW6faHIZCkQ34wIz/pehQ6 Ri7dA/bZeMvnBDvwhPdQT0SHMeWYKwxzA8K+JrvvSExWQDcTK0Ps3PRMomwuJu81uvzn8H YUlapD4VPg0Q1HsHuybDh+DIKLAGk8GmC7udcc0+yemOHuJmPiADRYCNpE/eOEJNSZRWZJ 5veY7gYPFOS8PGMRCyBqszHSKLG/GSON3WiqIW76kiMtRYBZqQlFYAyPyei/tw== 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 4Zk4zv1FqDz1K36; Thu, 24 Apr 2025 19:00:27 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Thu, 24 Apr 2025 12:00:25 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: April 2025 stabilization week 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 Mon, Apr 21, 2025 at 01:00:13AM -0700, Gleb Smirnoff wrote: T> This is an automated email to inform you that the April 2025 stabilization week T> started with FreeBSD/main at main-n276625-d4763484f911, which was tagged as T> main-stabweek-2025-Apr. The A/B testing at Netflix didn't find any stability or performance regressions compared to the March stabweek. My personal experience with a home router and desktop was also successful. The users of drm-kmod (mostly laptops) faced a problem. The packages available at the beginning of the stabweek refused to load on main-n276625-d4763484f911 due to broken KPI. Wednesday night required fixes were added to the drm-kmod family of ports. The drm-know packages available right now in the official repo will still refuse to load on main-n276625-d4763484f911. However, manually built drm-kmod from fresh ports will work. Hopefully, we will see updated packages pretty soon, too. There is also a report of regression in iichid(4), also hitting some laptops: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286045 With these two known issues we are ending the stabweek advisory code freeze. P.S. By the way, speaking of code freeze. This time it was not really held by a number of developers. Don't want to single any one out. Fortunately the stability/performance testing was successful, which made the stabweek fairly easy. If it happened to be the opposite, then the flow of functional check-ins during beginning of the week would really disrupt efforts to quickly diagnose and fix those regressions. Given that I was on vacation, and Warner was running the week for a first time, that ignoring of advisory freeze would not be a helpful thing at all. -- Gleb Smirnoff From nobody Fri Apr 25 17:06:33 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 4ZkfQJ6FR3z5tnN9 for ; Fri, 25 Apr 2025 17:06:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.82]) (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 4ZkfQH63Rvz3ZrW for ; Fri, 25 Apr 2025 17:06:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ngdFz+WJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745600806; bh=+Y2rfic5A3D/Wu59kHho/MPlpGMXaDaFNG46ECh48s8=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=ngdFz+WJOZq3Km/L35lfUajnk11GVKkfYM9b5kOhscX0L8gCP8pQufbU0ZDswJOXQzURnBoT1QFXRJ8AMK9fezsZF+Ves4ppCn+SKXjOlu4+lmHlggNAFCsY6oWPbS5zG/Fie121wV7ZD9DnD3wKt2IATycvmTlLo3yYZESUCfitc27owi2ngBGSzo14pYRnuqvyNs5JmCsneucH8SMQC9p+CAaZmckbc4l6ZGboO7zBXX7JHEIZ2hC8oGv3D22A6XchcyaK1IniNyw0yoGfpsiiQ5SM0qqSv29Tzrw+V9qxpRc2p0VN1RGx/JwhS586U/u0id/KiNsibjPLWJLPxA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1745600806; bh=gELIetZfgkk9gyrBd+U5SbTfQ34tecwdkj0pm9rzjJp=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jDwErxBOSe9ze+BYL3Q5UWRay+80/4O0u4V77kDPwysLb9CZ+ooRLkfM8nSQcz4IiAVsliwLaar+zo2qPV2m1eCjgD3mp2xhQe7WmB9mIAuPpPjZlrZOrbRj00gWq201yHPQgOnnYa4e4v90Ryg7rRQjK7lDBzRoppy/lrllFRHe2PTaGK48qNTt97NN9JmMf6IG2iv0jtbfGi/gj3tHc80/xC9sWCpWjjiJWOvnmjc8i0RE01zt7HAjIewJv3KJlN0JkEVYQDnPpdMW2OGFE49GlDXpLR3esbKon94APUD6hjAqhKdodAOQR+UuVqXndlEHRAZ3nvfOMhdQ4DYINw== X-YMail-OSG: yC8z7GsVM1nbtWONHF4YlnQ5eNG9oSp8rNj_nnqrM8iguZFfYqyhEVA6YTOrwV. vwx4pDdtftL.ghdFI4hdez0FmqlVI.OM2Gf8Ux.rCtO70xHxg_9W.d5bvITk7jjfExvZRDnRGi46 PI2iH0lpCsYt.zy3EokAtEgaO7m9_B4.69yxKq70fm6e3arUiqVGF66MKoqgytklhBH3N8NTZVOd WdjxJvK8CWMKCan54OB1piEOVPOqPHpljqffGY.mBquQOwaqiPk3aG2jkIZzj3SO.BkDRy7O.gUI ZHcmTUSsSKzaCKmmqLCgb93TohWMQoFhHkusGFI3MBSxxrDqW03jgZVCZgod55SpRS_L1qAi27Hc ufxdW0mzpySVEO4pitkr84dtEftEhpabupYeGZfwnKSrICroRqCtPu.kbWFiEM.7yzxxFhmnmOs1 BkBqygeZYYz05hYfEtTMr3nvmFGmWZA6wycKoHLUeGGVjxZ2j_.c19gP.dFFJikKtxme9Hawwijh PveLrE3Tm1EvsBuoG409e2u8aF3ztLtauFyyewFSED5s2eRpdGNyhMS3hNFvqyR3Tj_eHbUzfRxt nf3R62u5zYln8__6yWsEQcqQGb7ZZvLDi.MVmjJIsIRC_TfkJnMn8i8OaQbG5tW.MpRij5_RhLq6 GPpC2Z_Ke18USvB4UdlW4lHQGTnGgJYcDG4_6b6eCB_MyA82zT1_8eRYIEiagb_iqd2hCYGIZbbp cox07t_2034Ok3z.7YLTCMXepPRQZ7uc8gK7tane0PpZzDe_raw4w5.mmzy7pQH0iC8pmXb5vP90 t9JMUoCsly6DaXeT_ewfFiA1AxQYG8EH_OcTEmrY0TKZNRIrnSiCgLDM4jKKB76Xlh8pv3.ntK52 uHx2r.1LkkIqbuAOz31lV47jdVq2AVyxijOQF86XE_sYD_35IP34jDszZww_TeG0dQLTZ1j0gLEX KVnC.ZT5QtX4Ibc4TzK1ESi0cPdKlyYPkyx5POmTQ2mQ.LsYC5fILVarHS3JgBtAPXd0W8aL0itA cmDEcnfvpC28wWN0xd7nPhUQKPwYh.1CWf.cedMb8C.iLqTxbCk1asJJT9QndeZHnvAXzx.nfVhG laLAWsFGdYeS9lIJUBiBt42tfkLezA35_EyxXqW7znjvwJw8sBAzSJbv020.78Gw0XmdEzh5kQXW MIBS309_ExjaBQOS.AUVP7SdHPE3WFhGVsGtaKbmcq7jMEvlQKA3UxnIe3Vnoziv.T2olNitrgS0 .a1P2jx_AaADVBrBW2QV8NlTJMNlB71JqY51fj6f1zPzBsoSbE5hBfwPvrJvRj_O0kIoArrgwPKU Cd42lToOdLGdmjrieKfHaT7tkGi0Uy7BENBPhngEZQTMqKMrNr5SARkE1iE2RMiJbJRc7aql0a6B SKNFIRnHrGxiWrHcbnSG9t0gvuPgSYKTG_wNxCherKqQfh2fxSrAuWQMdCzuenorUsdGlrDCmDaj A_FrRGLNecCdSROiYUwNRt7gVaRDRUDpwHoYJEfQ0mx_YbaJUl2DIc7y3qffRQV.uNPW3BP4R49w oqwsP1wp7tRayHuBs9ST4BSjVGFGJdHqZWsK30Pdh6yVR_4xN4q0TULo8oJuvdqcH.7psLZGZp6C 4UPyJX534ao4NRGtxhTj_oPsvDfOinfcCs4CmZ8WTDWO0iNoBJ7Vego4M3Y6JL5AHg2uxxyxjgrK g_tgNwMM_81JzPAyfPkkSo2s.K9ZXA3hzStRUGHDH8uWPhKffaAoTjnNvBVIIhrXkkGiSWb_bU3W bUqeNa_jirKfYo7.iT4DmhXbHFoDleAfyRG6DnvC7laZSO368s.gfOoZcYkXqYLSFIsBb0PVFjJq 30qvDvDDJZb5s6uBnELySPkExEEVolVLAlz7ASoCQ8JH.jLEaDnOsl0FciWRU.AF1q12LmC7uqLl XcTiZ0wCh.nF5_qbOBMgnmRK6E0wBl3d9ADNCGvrSvnIDXnGaFYe.gLRRG_RpxfIEpp859Jumwhj jhw9jlPj2Nm1RPfnZcVhXLGp5CZBmc7vn83FOeTyBqSLXZe3R839iwgx7p_sbcnk9PbJGtLUAYdS UP_XN7ZAgF_BfRC_upcyrYjoUFIo7EUTi2Z0AHKQS94j.ZYQdq9vLMK_Ads5PZg2xCQ3wcgKFLRb j1vrDMN2n4edR826yaplcj3iqmVqMUuu1ag3m0t8Cy3jDy402yMdOpyUWkdXiJ62DR5wu2NhgoCt h5vvHNUMJsGfNL15J1QGgOQPPU6bR3Id7uO5bDdPOiyvJo0ovFDDm_m_hJLXOmeQCvGL3KEc2nYC 7Tg-- X-Sonic-MF: X-Sonic-ID: c40be816-e2ee-4683-93df-f9eabb751e93 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 25 Apr 2025 17:06:46 +0000 Received: by hermes--production-gq1-74d64bb7d7-4ndhm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 04fcd78ebd914db5aea0055b68b5b1a1; Fri, 25 Apr 2025 17:06:43 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: zfs (?) issues? Date: Fri, 25 Apr 2025 10:06:33 -0700 References: <61B5E2C7-EEF9-4DD8-8BB3-77B530FE1565@yahoo.com> <2CD25DE4-2F94-4D00-A39B-1A1F24C263C0@yahoo.com> To: freebsd-current-freebsd-org111@ketas.si.pri.ee, FreeBSD Current In-Reply-To: <2CD25DE4-2F94-4D00-A39B-1A1F24C263C0@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Spamd-Result: default: False [-0.95 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.86)[-0.858]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_MEDIUM(0.41)[0.405]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.82:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4ZkfQH63Rvz3ZrW X-Spamd-Bar: / On Apr 22, 2025, at 21:29, Mark Millard wrote: > On Apr 22, 2025, at 20:27, Mark Millard wrote: >=20 >> Sulev-Madis Silber = wrote on >> Date: Wed, 23 Apr 2025 02:04:28 UTC : >>=20 >>> yes, 2 * 8g partitions on separate disks, so i have 16g swap >>>=20 >>> . . . >>>=20 >>>>>> Van: Sulev-Madis Silber = >>>>>> Datum: maandag, 21 april 2025 03:25 >>>>>> . . . >>>>>>>=20 >>>>>>> others don't get it at all and only suggest adding more than 4g = ram >>>=20 >>> . . . >>=20 >> I have no clue if this will be of any help. >>=20 >> For 64-bit systems, having total SWAP much greater than, >> say, 3.6*RAM normally produces a warning about potentially >> being in a mistuned state. They look like, for example: >>=20 >> warning: total configured swap (477183 pages) exceeds maximum = recommended amount (466816 pages). >> warning: increase kern.maxswzone or reduce amount of swap. >>=20 >> If I understand right, adjusting kern.maxswzone makes other >> tradeoffs that I do not know the details of. Thus I avoid >> getting the messages by adjusting the SWAP space size >> instead. I've been told that the messages suggest a higher >> likelihood of deadlocks happening while managing the memory >> space.(Others may known what they are doing with >> kern.maxswzone adjustments and could judge the tradeoffs.) >>=20 >> Are you getting such messages on your console or >> that you can see from "dmesg -a" or in >> /var/log/messages ? >>=20 >> (The detailed multiplier changes some from system >> update to system update. I can not report a fixed >> multiplier. I leave margin to make it unlikely that >> I'd get the notice across various updates.) >>=20 >> 3.6 * 4 GiBytes =3D=3D 14.4 GiBytes SWAP, as an example. >> Then RAM+SWAP =3D=3D 4.6*RAM, so 18.4 GiBytes or so as a >> memory space. >=20 > Going in a different direction . . . >=20 > Are you going to publish step-by-step instructions > that repeat the problem(s) that you get in your > context --with notes at/about the failure points? >=20 >=20 > Also, you wrote . . . >=20 > QUOTE > i mean it would be easy to add huge amounts of ram > but people could also want to use zfs in slightly > less powerful embedded systems where lack of power > is expected but weird fails maybe not > END QUOTE >=20 > The Design and Implementation of the FreeBSD > Operating System (2nd edition) book says: >=20 > QUOTE (Page 49, last paragraph) > ZFS was designed to easily manage and operate enormous > file systems, which it does well. Its design assumed > that it would have many fast 64-bit CPUs with large > amounts of memory to support these enormous file > systems. When these resources are available, it works > extremely well. However, it is neither designed for > nor is it well suited to run on resource-constrained > systems using 32-bit CPUs with less than 8 Gbytes of > memory and one small, nearly full disk typical of many > embedded systems. Thus, the fast filesystem continues > to be the file system of choice for these smaller > systems. > END QUOTE >=20 > NOTE: In my interpretation, the "32-bit CPUs" vs. > "less than 8 Gbytes of memory" context referenced is > that there is a problem if either issue is involved: > CPUs can not substitute for needing sufficient RAM and > RAM can not substitute for needing appropriate CPUs. >=20 > QUOTING MORE (Page 548, 2nd bullet) > Like all non-overwriting file sydstems, ZFS operates > best when at least a quarter of its disk pool is free. > Write throughput becomes poor when the pool gets too > full. By contrast, UFS can run well to 95 percent full > and acceptably to 99 percent full. > END QUOTE >=20 > I'll not quote about the mmap details that is one of > the things that "works less well than UFS". (4th > bullet.) Actually, the following quote seems useful, as it is tied to extra memory use . . . =46rom "The Design and Implementation of the FreeBSD Operating System second edition" page 548, top line and then the 4th bullet, end of 1st paragraph about "to ensure coherency whenever mmap has been used on a ZFS file":=20 QUOTE The areas in which ZFS's architecture works less well than UFS are as follows: . . . This approach provides coherency between memory-mapped and I/O access at the expense of wasted memory due to having two copies of the file in memory and extra overhead caused by the need to copy the contents between the two copies. END QUOTE > I've no clue if you have a ZFS-based problem, but if > you do it would not be surprising. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 26 12:01: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 4Zl7bG4DlNz5v6BS for ; Sat, 26 Apr 2025 12:01:14 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4Zl7bF2Pyqz3NN5 for ; Sat, 26 Apr 2025 12:01:13 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=iHSQXaoT; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1745668863; bh=nUwRAPwJ7wSCZqIVDZJi5YUJG16JdH4aIHc7uho9HVo=; h=Date:From:To:Subject:In-Reply-To:References; b=iHSQXaoTF8773noRXypNf6mNcVD2eh5pEkhasRxZOnfr7QR+CzAmdiVutp1Gsk//+ 8tCzljt03zRLMOTabNVbdA4FPBxRtWKFRPf+jh9cfzMsGZY1RgDIqAeeVzuyggsIG7 XoJZyr5G/sjM2XrEq3lpZaYFibrJqhGjL/aD0RSMfm2YtM4USf9yURD3Ijztl9joD6 bBAxorNY8bhkkaW1Pl1Zz4W8ncYfS3ie8wYHtiGf2JSdYJlJSl37p56NJd4MnqFPCK hgk3fccADhvYwR33XpTZb8OUN66Gfyuwt1Fnc2nopYFWiHuQO2v2aQCv3zdDYdin5g XUJUBEVKfyn9WWIUh3uR+FsaUF/PPCBoAdFQzrvdrevZ1Snym3Co7ZZD/6Sz9ebbRu muKM1frYrztNH/UOmxeelxXsc2Q00suggJhx13MLL78F+LEAOXLvvriQLqSEkrxkvp fsK3MBH0A2xzwWbfQzDDQBpeh5N64ccyyLGAH2BgYIF//ThoiW9CqayBpYxdRn50w5 J3q9RTFJnEqmPVQEWjI2IFMW4kNDWDNAI23v3nailiE4IVEt5fezHWneb1wRVx5QmV r7GNyaIv9cyXyLZl6X6650IQhNQD90C1Es6hwfb0yNH0Wby8F8Uti4biD+FjQw5YFX jcx78kJnxxFwQhEqR0xg9+JQ= Received: from [IPv6:::1] (0114-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::114]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id E67325A4A2F for ; Sat, 26 Apr 2025 15:01:02 +0300 (EEST) Date: Sat, 26 Apr 2025 15:01:01 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: zfs (?) issues? User-Agent: K-9 Mail for Android In-Reply-To: References: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> 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-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [0.75 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; NEURAL_HAM_MEDIUM(-0.45)[-0.452]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(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)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4Zl7bF2Pyqz3NN5 X-Spamd-Bar: / On April 23, 2025 6:40:44 PM GMT+03:00, void wrote: >On Mon, Apr 21, 2025 at 04:25:16AM +0300, Sulev-Madis Silber wrote: >> i have long running issue in my 13=2E4 box (amd64) >>=20 >> others don't get it at all and only suggest adding more than 4g ram >>=20 >> it manifests as some mmap or other problems i don't really get >>=20 >> basically unrestricted git consumes all the memory=2E=20 > >I see symptoms like this on very slow media=2E That media might >be inherently slow (like microSD) or it might mean the hd/ssd is worn out= [1]=2E Programs like git and subversion read and write lots of small files= , and the os/filesystem might not be able to write >to slow media as fast as git would like=2E=20 >[1] observed failure mode of some hardware, where writes just get slo= wer and slower=2E > >[2] the workaround where the machine *has* to use micro sd, in my > example, to update ports, was to download latest ports=2Etar=2Exz and > unzip it, rather than use git=2E > >[3] test hd performance with fio (/usr/ports/benchmarks/fio) that might be it!? there is hdd on machine that was tested but now never r= eally likes to complete the long smart tests, and short take ages=2E there = are no "usual" disk errors, tho=2E that hdd is part of 2 disk mirror that t= he git runs on but there could be fix for this that never affects people=2E i don't know = how internals really are but slow io could fill the buffers up=2E those can= be checked and fs could be limited=2E eg, simply not telling that write wa= s ok yet=2E that would make things slower if queue is full, so git would wa= it=2E i bet that there are checks for it, maybe they just don't work well? = it can't be just blindly taking writes hoping they could be committed up to= storage in some future time or i could be wrong and it's some other issue i'm wondering why noone else spots it much, tho? because io could be slow = due media being abnormally slow by design=2E or it could be failing=2E but = it could also that influx is just past what storage can do=2E and this coul= d happen in fast machines too=2E or it could be happening due accident or e= ven attack=2E if i get this correctly=2E oom protect won't save any userlan= d process here either? so it truly was all about kernel wanting to allocate= all of the ram=2E which it did=2E i didn't see single userland process run= ning iirc but i couldn't check either=2E kernel itself kept running perfect= ly fine after that=2E fix of that particular failure is to enable watchdog = of course=2E i think i've seen it on another machine as well but never real= ized=2E or maybe it was hw there and kernel was also frozen=2E when i turne= d to check, i found caps bulging if all up is correct, it could be easily tested, with gnop maybe=2E i don'= t see speed constriction option but i see delays=2E maybe even i can test i= t now, as it doesn't need huge ram just to prove the point that it fills up= completely and this is not fixed on current either? and fix is in zfs? and ufs, as te= sted by others, would not be affected=2E=2E=2E why? i know zfd does cow but= =2E anyway, i can't figure it out=2E that's why i don't dev fs'es=2E maybe = tell kirk even? : p what's funny is how kernel knew to stop there? was it just because it fina= lly was reaching actual ram limits=2E or just because writes stopped due ki= lled git=2E i'm not sure what kernel memory full could mean=2E panic always= ? since you can't kill things in kernel=2E or it could give errors or delay= ? like completion of syscalls is delayed? i'm unsure about all this=2E i'll= leave it for others=2E but it's often told that, like, full memory in kern= el leads to panics=2E couldn't it just error out? tl;dr - suspected issue of zfs on slow device filling up *entire* ram with= write buffers, leaving userland killed and system in unusable state From nobody Sat Apr 26 12:49:45 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 4Zl8gF6VLlz5v9GL for ; Sat, 26 Apr 2025 12:49:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zl8gF5tkdz3T9c for ; Sat, 26 Apr 2025 12:49:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745671785; 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=97U28Rf9eJgQX1MJDdrPVZlALP1NnkcfIUD7kunFobI=; b=HlnJAWkSq+qPlzPJlUB4NZA2QpRyKmvX+8xr0r0a5VQfRDbaZLz/Ey207BTWzwry9gfouy 7HQq40Mib5n2P7He6wfZ0PcxIll3e2bqVyAQ5g3zTA8JS4TF2G/cmZ9pkd1pKTUpe7to0y UC2cBkfxw5FF/6o1VgtbsC5d0pe2HaWL++QgCqusQOJfC2OuCc80yz9BEXw92JaAHCxF0N QhPisEJ2tqlM84RfBbQBFxTMmj5r8JcEYFR0aec8qYACZoUivYwlMdGGAMqinuXdeGy20f yYjFgsYelolAV9tQyZDgZprlYVBiiU/eJlzxvEE+nFVbkASaPeqXKRKSvKxcbA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745671785; a=rsa-sha256; cv=none; b=lam9CBcPHZo1cH+FZVtrNUAmrio5cchuBEbSLvSkwCVyWlgkKtGO1lHDKA5BWFSPeDb0mg n6p6zyviQ0afVVOVPVsZuMEyvQAvcxKjkYZr9gDkwEfHePhKImOjdYmjj8fxFt3zaYhMN8 Z2fmvki/tnaYFkRngyZt2bFwtFPi8AdUt/q0/IX9rJX6CnXdQng7Hs/w1V1avf96kRwFZn SDZZhCe4KMa4hCK0c9jXzxFY+EpaSrXSgSFdzNR07jpB+aDo8TlB86XiD9WUm2DCGXh+Y6 ByuSw+1YavCy0uY1jbheeJNhZRUAMtbUH7ZEKenj+7RlU/o/NWNzCScZWwll7w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745671785; 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=97U28Rf9eJgQX1MJDdrPVZlALP1NnkcfIUD7kunFobI=; b=wDT7nrFljAkUEcP0JlGZji8Dg2C85Usx+Vu34cvaRnXTUO44p5opy7ggyduzhtfslWsXTq wbJ9/QeIL4HDc+Yto5FISVO5yjP6e8jw/reybyoO6sTQz3GbTDKHfTXXgRZJxkbm/ZepK+ Xj0Iw0hxLL0wQ9TaiDHZrA9sNLFqQIAseAdCjidI6AMz8+7LVFOo2Uq052xQBLbQvg9a0s FfVCRSEXgA48sFNBqWK5jvkhm43P9wOLcPu+E3q3lcnmDO8ql09VvrDUEaajRubjAZ4+C8 ilkJHporZE/zIW/5bQCKhfMs+S+jPKT/9DRwF39EwRbsBjxlStMnydHdOcwDQQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Zl8gF5TJ9z4dx for ; Sat, 26 Apr 2025 12:49:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 53QCnj1O070826 for ; Sat, 26 Apr 2025 12:49:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 53QCnj93070825 for current@FreeBSD.org; Sat, 26 Apr 2025 12:49:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken Date: Sat, 26 Apr 2025 12:49:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: zarychtam@plan-b.pwste.edu.pl X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285044 Marek Zarychta changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 863 | |56 --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Sat Apr 26 13:06: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 4Zl92P4KpGz5vBC1 for ; Sat, 26 Apr 2025 13:06:21 +0000 (UTC) (envelope-from void@f-m.fm) Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) (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 4Zl92N29Pkz3XLK for ; Sat, 26 Apr 2025 13:06:20 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=joxFVPXg; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=tIiaAfee; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 103.168.172.151 as permitted sender) smtp.mailfrom=void@f-m.fm Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id B4ACD138084C for ; Sat, 26 Apr 2025 09:06:18 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Sat, 26 Apr 2025 09:06:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1745672778; x=1745759178; bh=+SVTNcsmQn 58hVqhVpFJ0Pq7Rsld2IhsKalgwrW6sCY=; b=joxFVPXg+107BTjUqm2WVU+Smh D/4MxpLsVfBwRLo8Gsq5NWDU7M9kDE0sGiFlgmMX0yuMaADOzvkmRC9VyuBSd1uQ La42EN90pWIaoo4cYPAM9j0iukcLvVEDMDgvn1zeuzjng9cYh50fh9e5rJz4mLOF ivYJdm1jbnfzbvQTzoi3fhbDn6Zu01202+Yif3jT/bd+lPS6d/eKF82HbAI7DKpS +qDJ6nNl7MP+iyWRop9qf9H1ycIfO7tlh5YS4hozRZIOBaM5yCB+84QQhyqkE+fC 4FguGTz1AeqH3eblu/yXlSoCD2SXKLUIKMV4fW8yYSIuBkev2JBpJi5iCFzg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1745672778; x=1745759178; bh=+SVTNcsmQn58hVqhVpFJ0Pq7Rsld2IhsKal gwrW6sCY=; b=tIiaAfee5suOlQEwl6wWxr4g/wD5hc2cqft/I83HTVWGZIBQFwQ WtIxuurnHCv+TNiK4Ey14eeyYW9BH6V4koFLRPDVKPIeU25c/rw0gEUHVlyBuGag V37677rEjedNezkxg73pqSYVDvmlcbcF2baZYKNKLbsWAwuw0FvFtO5UTwJJe2h1 mHiq9f6D9se12SxSUo4zAcUFk7y2jFI37L/+ZRM6kNitUHEkOuYYAfhslgx1UxVu 3UB/gqURpMugtttFI1wGhp3zpNiiTS4o2romxr7UQ2GOMpulinqXlRin5uANA7oK bg91qhPz/wENcyd10ZL2hHLXCEiKzZvTZsQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvheehvdejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhf fvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehf qdhmrdhfmheqnecuggftrfgrthhtvghrnhepkeeluddvlefhieelfefggffhffektdehle elgfdugfdvgeekjeejuddtheehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmhdpnhgspghrtghpthhtohepud dpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghn thesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 26 Apr 2025 09:06:18 -0400 (EDT) Date: Sat, 26 Apr 2025 14:06:16 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: zfs (?) issues? Message-ID: Mail-Followup-To: freebsd-current@freebsd.org References: <56F52DF4-2988-4F06-9F53-90D07AF5DD02@ketas.si.pri.ee> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-1.15 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; NEURAL_SPAM_MEDIUM(0.45)[0.452]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.151:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[f-m.fm]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4Zl92N29Pkz3XLK X-Spamd-Bar: - On Sat, Apr 26, 2025 at 03:01:01PM +0300, Sulev-Madis Silber wrote: > >that might be it!? there is hdd on machine that was tested but now >never really likes to complete the long smart tests, and short take ages. >there are no "usual" disk errors, tho. that hdd is part of 2 disk mirror >that the git runs on These are exactly the symptoms that led me to junk 2x HDs. One was CMR the other SMR. Smart tests failing to execute normally is a sure sign it's hardware. >i'm wondering why noone else spots it much, tho? maybe they do but in the end attribute it to hardware >and this is not fixed on current either? and fix is in zfs? and ufs, >as tested by others, would not be affected... why? I've also seen the same thing happen in a microSD and a USB2/3 context, both were UFS2 not ZFS. >tl;dr - suspected issue of zfs on slow device filling up *entire* >ram with write buffers, leaving userland killed and system in unusable >state Going by what you've described here, I'd say the problem is down to hardware. -- From nobody Sat Apr 26 15:14: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 4ZlCsy33xdz5vK3B; Sat, 26 Apr 2025 15:14:14 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 4ZlCsx5DZgz3hVD; Sat, 26 Apr 2025 15:14:13 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=JRYJmqyU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5e8be1bdb7bso5150472a12.0; Sat, 26 Apr 2025 08:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745680452; x=1746285252; 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=dbg0Qr6FMEja6aAhz5OvXIIIOunroMN9zmtJLljYap4=; b=JRYJmqyUj7oHUEywP7KDTj9UgpKsTEf9iMjF+qIEbfWjMG56x2bLK4/IcPjEaWDH0Q assZgGoIAzDH96MUxehVLY6HErLOnmXeHN6pX/H4g45AKqgxWeO2SObxJNJyNDjHLf7Y gJThB+ju2XHndQF2pSCzFnXKP9cIgBhnmtqVD2FeAhIDhyUKpV/irZv+M3k+xPWFm1K0 +d+wAx+8uo8bZpxjzqAQM2xKYvCbq2KOGzr1FkejDke4hTCOB6HiIhyM7GoqN8wwpQRo aLlZyboqZG+MeKYmyo/lN7okfMxdvwG2xHesFtGs2bn1Ftt9yEV0rLqE2f1mUKZn6++u INzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745680452; x=1746285252; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dbg0Qr6FMEja6aAhz5OvXIIIOunroMN9zmtJLljYap4=; b=twWwNybtSk2lVGlrVRkjXo86swYWs93Jt2GoXafCUL/d6iGcpSAfpKvsg3jCQ+y6xu fOZ+N5C3afVoIHlMY4Nfgv27jmVSCWUxHPoggDnrmYxJyqXnkiAX5Z8ENgNsEHSVOMkn PZgox/uJiiwXpYZCpVfJil81JKB7L9JJmZauP+a4JObR1wvDo+tolE6tWaH0O85ByqvI KisQjXXQZfFKDJEwVANbKgVNEc3r11wm9av21Pzzmzk+c4S4siSvtVjoa2NTJqUr+w9Y H19aTGXyNIVe12uIUjLfC/yUeN0v0pyMJPrR8MkRJYHcOLVqG5+tRzItkJm1bb16AnjW BUIg== X-Forwarded-Encrypted: i=1; AJvYcCWHiJv5I2qK2FLk5ciCcDs/DVTMZDA/VFtmAjcb2JDL0vA53/gHnLjgVge9h+FXaRIZ6DPn35C/qyx72edcM4s=@freebsd.org X-Gm-Message-State: AOJu0YztxXRh6H1RV/UR75vOlDi6JllSQW5LpLlUlepXkkVuwFejJIOY lNkIBHZSK7d9xuD3arjRD+WdKjtU7FvRMdU/s8/v80sPm3wOrhP0s/igIlQmlgIpPsODeJYu4QG iKCqq7bAZt3kjAUCWbsDGMHOPXaRj+Ag= X-Gm-Gg: ASbGncuX7sr73UfrBN8sEDnby0An9YAuFiUYFlDaImIm6eBKZfYsluG0F/Td5Tut1n9 gP6L0yeXCMVFs7vdqjlVBKE2nYH6kKy9XyI4m91U4M3D3pk/zcEvDuFsONvt6lt8tqETZ4U05SO 5tHdkFV0YPyzWx/XCG1+pn9aKi/0iyLf3ZMUQhsevqQB6gOqDjmEX6Sg== X-Google-Smtp-Source: AGHT+IFo9x1RR8QNzpwa0xsogDhALwSwrLkUIKkxSowO/Ok53Qzr7yO1XMkWpoO98tpgGaVIO0Xtb8lQMS8i8dLcy/8= X-Received: by 2002:a05:6402:5249:b0:5ed:2e84:4f1f with SMTP id 4fb4d7f45d1cf-5f72352b03bmr5201572a12.22.1745680452008; Sat, 26 Apr 2025 08:14:12 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Sat, 26 Apr 2025 08:14:00 -0700 X-Gm-Features: ATxdqUF4nP120f8X46blOBV5vaCRz-zdyUxWIofRFV5oIKGkmSVbodpLQXG0Ox4 Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Cedric Blancher Cc: freebsd-arch@freebsd.org, FreeBSD CURRENT , Lionel Cons Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.91 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.995]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_MEDIUM(-0.92)[-0.920]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZlCsx5DZgz3hVD X-Spamd-Bar: --- On Tue, Apr 22, 2025 at 3:34=E2=80=AFAM Cedric Blancher wrote: > > On Sun, 9 Mar 2025 at 00:02, Rick Macklem wrote: > > > > First off, I cross posted because I don't think many read freebsd-arch@= . > > There seems to be a nice market for Solaris style extended attributes. > > Since ZFS is already wired for them, adding the basics is pretty > > straightforward. I am not suggesting that they should replace the > > current FreeBSD extended attributes. > > > > For those not familiar with them (I am not very familiar myself;-), > > a Solaris style extended attribute is in a directory that hangs off > > the file object and the entries in the directory (the attributes) can > > be manipulated with open/read/write/lseek just like a regular file. > > (They can be as large as a regular file, but there is no atomicity > > guarantees.) > > > > At this point I have a couple of rough patches: > > https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part > > https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 part > > Any timeframe when > https://people.freebsd.org/~rmacklem/nfs-xattr.patch will land in > FreeBSD? Should be in main in a week or so. I have already done one patch commit, but there are a few more needed. On the bigger picture... I have finally gotten Solaris going in a VM so that I could test stuff on it and have found a couple of incompatibilities: - I required O_CREAT for nameddir_fd =3D openat(file_fd, ".", O_NAMEDATTR, 0); to create the named attribute if it did not already exist. Solaris does not require O_CREAT for this case (when used with O_XATTR) and actually returns EINVAL. Solaris just creates the directory if it does not already exist. Changing this is a trivial 2 line patch and I think being Solaris compatible makes sense. I required the O_CREAT, since I was thinking the syscall without it could be used to test to see if the named attribute directory exists, but I am not sure if that is useful? Do others think I should change the behavior to be Solaris compatible? - Solaris allows hard links to be created to a named attribute. I did not allow this, since I was concerned that having links to the same attribute for multiple file objects might be confusing. Do others think I should allow them? Thanks for any input, rick > > Ced > -- > Cedric Blancher > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur From nobody Sat Apr 26 16:06: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 4ZlF2n02c7z5tPDy for ; Sat, 26 Apr 2025 16:06:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZlF2m5v1Bz3rtB for ; Sat, 26 Apr 2025 16:06:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745683616; 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=xi84KpB6ERckWYRz1ZcL448bokLHf31TV3sji701/Sc=; b=b7erL7NdWcJ9ESz/1nCUbhL5Wm3h5WbO2L8xqLU3CQHvj3QybO3ejwYnISA2xSnHLIBz3C LVz2Qhd4YEesqpNNitCOpU/QWvDKxZRLXqo4q56F1H5fJBx0LQ5E3CxNVX31mlNjbWIKdD c7v3Gsmv2JQ6muzbSBSpjSTeWUy8biwimjKzLEUDiOfFccDhW0wyq4NK6b2O7Zm9D3GBn2 4lQt8RfFDPsRXCn7BkXtnzhu1VdCLmzkS9TkMIDCWzpxAN8iqIXQ4/NJTbGPEemWZ6ceH2 K/R9MUTmhGp+j7uOoUdDrl2ZvWWnfKWjH8p1FxsZlPEV04sa/Fwl49yizZbzfA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745683616; a=rsa-sha256; cv=none; b=rUQ4+zB1/qKqKCyKrLSQlRQTkO5zgoobnGwbFsfdpMbCW21Iwislqdgl4OCeQU075sS2J9 sHFWaib8z1orSD34d6eprcpeBrUSbB95VLBdP9cscGCBOfIkbiT7YBPVS1RHFJm9HddEdU NmwOhf/fvGa8M7fi+HOlWReizKPjsstsCvqjP8iTduQsD/LSy14u/Bt48bbAWxLcE+a/en DmJhTxIEDIlhVySf/TKb2GQ1Y1vunA7dStz/d5XL/ZFN9U9ibwu4IlBzwuVYbo9cf/Xs5/ uPihME6pEFcwsX50n+/pDkxYlYj8+chuL8XOZaVIMXSOfUtf5QF0jGg6Efom0g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745683616; 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=xi84KpB6ERckWYRz1ZcL448bokLHf31TV3sji701/Sc=; b=xUvYW2QfLEeqRDqdmwhydQzID/km1/PjxXKtSZ0Mz5BCdI4XzSM3gIhT+tcjLAtWi7KaP2 vlLHwRLMsYIq/JcxUFn+RbsCVtvdKrWa4BtjfUfSQwAhk+TFXSf8ITMFdp4AXSjFwpH4Nu OZ7SBtKlwhSs+u4yec03r31spNV9gyWEJJFR1Upt8NMgTvdFUZ/Vh13GJBY3vzZADZXG+O dRSbquA9joCJ9PVolPAyD0NpG3yXVkq9FnJUVXJLCary3PGHmgo1sMHoqk97H7g2g2qu0G 1zPrxZp8JlBr6bYnMlcyD27yz2se2PhLungHE8BJ92/MHAIG9UjrSfbzLMHh2w== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R11" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZlF2m4Q49z14bl for ; Sat, 26 Apr 2025 16:06:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow-wifi.home.andric.com [192.168.0.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2165B3E409 for ; Sat, 26 Apr 2025 18:06:55 +0200 (CEST) From: Dimitry Andric Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.10\)) Subject: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries Message-Id: Date: Sat, 26 Apr 2025 18:06:54 +0200 To: FreeBSD CURRENT X-Mailer: Apple Mail (2.3731.700.6.1.10) Hi, In https://cgit.freebsd.org/src/commit/?id=2e47f35be5dc I committed a change to convert libllvm, libclang, and liblldb into private shared libraries. This means that tools like clang, lld, lldb, and more are now quite a bit smaller, as all the common functionality is located in those shared libraries. Note that these shared libraries are not the same as upstream's, and are _not_ ABI compatible, which is why they are installed as private shared libraries. If you need ABI compatibility and/or the llvm-config tools, please use one of the devel/llvm ports. This affects the following binaries in the base system (some of them only exist if they're enabled through various WITH_XXX options): - addr2line - ar - bugpoint - c++ - c++filt - cc - clang - clang++ - clang-cpp - clang-format - cpp - gcov - ld.lld - llc - lldb - lldb-server - lli - llvm-addr2line - llvm-ar - llvm-as - llvm-bcanalyzer - llvm-cov - llvm-cxxdump - llvm-cxxfilt - llvm-diff - llvm-dis - llvm-dwarfdump - llvm-dwarfutil - llvm-dwp - llvm-extract - llvm-link - llvm-lto - llvm-lto2 - llvm-mc - llvm-mca - llvm-modextract - llvm-nm - llvm-objcopy - llvm-objdump - llvm-pdbutil - llvm-profdata - llvm-ranlib - llvm-readelf - llvm-readobj - llvm-rtdyld - llvm-size - llvm-strings - llvm-strip - llvm-symbolizer - llvm-xray - nm - objcopy - objdump - opt - ranlib - readelf - size - strings - strip In addition, all these executables are now position independent (PIE). Please let me know if you encounter any problems resulting due to this change, as I intend to MFC it. For example, I tried covering all incremental build scenarios, but I may have missed some corner case. -Dimitry From nobody Sat Apr 26 16:19: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 4ZlFJj3H9sz5tPyw for ; Sat, 26 Apr 2025 16:19:01 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZlFJj2YY1z3tSQ for ; Sat, 26 Apr 2025 16:19:01 +0000 (UTC) (envelope-from wulf@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745684341; 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=Rn2mrqUHs7dp2cE9LtxFBUlLv7Nrs8IgNugCEt6WEGQ=; b=kfOE3GR4Na1mEpw+ou8PT6rxsjsd+zhTCtM0SbZ4pr8nmQ5BCKz8CFEddxSUq7Ks0wpydQ QUKfAj/JHsPifaYA9IpR8YvUiF5MZRYRMG9o1mzqo1LR3oQdGUYUy3VvNPxP0WA2igcKKJ 5PSmQx12Wu7ZgKjlQZRnFUBBOsrYBxnTx0m3+TQ8ntYRsniy4esXs294pdJHMyw5rjd6AD OXGtL/qE1GAUZ35+M2WQHVe+wiph1HN0MX/tZQSDOX8HxpxRmxdoR/kFlt+pGa8x9Tptg1 f5Pl1DRdHRO6SQAV6G5s3UBIw5mdALEGqDCwayyiEnpKgHcl2z3oeUGlU2oSWg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745684341; a=rsa-sha256; cv=none; b=OAd+70oUFrp0wwbwyIcFBpT/L7B41/x/bRJb8127/0cqYOJ1wqi9GlZYUcFZ2VtuPj6y78 38arrJBHXNuBimelEITEcSiMog3mzzX3bnNmPTxZ7EiYXO6fD90TeDtZGkh41zMXF+DdXP VyTFrlqxFUKS9YdVE6eAhcVKtZ3eQZrWy1QdLuaNuoK9gWFAnd2vyzBLyuXdDJ6sRI3Hw9 YlZR3tSfjvleezUGWcy5DAWIuwgOVyMuO7s5YGdDodVdgMmR2gyYSxzNArKcVJc69j4Hzu aTLi9oWgqZTuotjd97XwP/x+j2lnhF2mccWdiNSoiHIBvXOGSqCrQRJ6zRk6pg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745684341; 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=Rn2mrqUHs7dp2cE9LtxFBUlLv7Nrs8IgNugCEt6WEGQ=; b=F0IpWLr8k8Ikdr9qRb1H6KqoQN1jkZj8JqIwT25Dd8Kdc6i0hWcmOmWPfam1672tDa8wEz QLULBz8haRGmGc2RU3RCLOSZ4VRFQ2Sb/V1l3KYcXiNLGEr2GWyJzhA8k2N3Muhb1VUL5j ZX7INi7iq4SOlFC66UpQNn249SnHSwAZxh/5NALfWkzBlWwK34WzfpNZ5Z0gtZmuNXVCti BjBLlRcNzIZQyYjHBK1PWsNf08lrM2/rh8nRoKlBYPCzr+CPXCrQsoOlJ1rBGsTUBmhnlf afXU8aGPd37QFyb3xGDVTLRN+LjuxJpwXzlpg+YbXLA1ViFSwU+51CassYqRFQ== Received: from [192.168.0.30] (unknown [176.120.234.130]) (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: wulf) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZlFJj02wFz14SW for ; Sat, 26 Apr 2025 16:19:00 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Message-ID: <7c4e115c-f0a5-4462-a34f-38291770aa92@FreeBSD.org> Date: Sat, 26 Apr 2025 19:19:03 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: April 2025 stabilization week To: freebsd-current@freebsd.org References: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> <4aad4a70-a953-458b-ac37-675b6901f28c@app.fastmail.com> Content-Language: en-US From: Vladimir Kondratyev In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/24/25 21:46, Gleb Smirnoff wrote: > On Thu, Apr 24, 2025 at 05:48:46PM +0000, Dave Cottlehuber wrote: > D> On Thu, 24 Apr 2025, at 17:31, Gleb Smirnoff wrote: > D> > D> This issue actually came up last month but I had no time to > D> > investigate > D> > D> then, details > D> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286045 > D> > > D> > Is this regression since last stabweek or from an earlier point? > D> > D> Just since March stabweek. > > There were no changes to the driver :( > > Any chance you can make a bisect? > I think it is regression from daa098cc37b9 Test this patch: diff --git a/sys/dev/iicbus/iichid.c b/sys/dev/iicbus/iichid.c index eeabf817616..d82beb52d58 100644 --- a/sys/dev/iicbus/iichid.c +++ b/sys/dev/iicbus/iichid.c @@ -630,7 +630,7 @@ iichid_intr(void *context) error = iichid_cmd_read(sc, sc->intr_buf, sc->intr_bufsize, &actual); THREAD_NO_SLEEPING(); if (error == 0) { - if (sc->power_on) { + if (sc->power_on && sc->open) { if (actual != 0) sc->intr_handler(sc->intr_ctx, sc->intr_buf, actual); -- WBR Vladimir Kondratyev From nobody Sat Apr 26 18:25: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 4ZlJ6x488sz5tZjV for ; Sat, 26 Apr 2025 18:25:45 +0000 (UTC) (envelope-from jgopensource@proton.me) Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch [109.224.244.17]) (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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZlJ6w6DmBz45ZL for ; Sat, 26 Apr 2025 18:25:44 +0000 (UTC) (envelope-from jgopensource@proton.me) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=proton.me header.s=protonmail header.b=SVItRQlG; dmarc=pass (policy=quarantine) header.from=proton.me; spf=pass (mx1.freebsd.org: domain of jgopensource@proton.me designates 109.224.244.17 as permitted sender) smtp.mailfrom=jgopensource@proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1745691942; x=1745951142; bh=oVO9YFGlH9/vI9nxZGJuIm7ZpLZTIRBq0N4QlhM1xAw=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=SVItRQlGcbAicJhw59RZ7t5kZ8cLS/BY9b4lxzoCtCdAa9kbn8rqWniUWUMKOSrRs O2onPX/rSieXIItKCMh9bI4Ab+jgs7F/pNemSl/EKPGann8UuDEE66Q9xvr2Rj3fHs GLmVS489xbUbdEzVwEZbUKYD0eHQDZOPS0dyTTboEp7rfEAhJ7a6QUVnKQtCLnioY7 L7Y0d32GJxl8R7Z2ZlyyXsmTyHrZTwfAhOnPsiUxjVZ2EZKwnM4RTC48HYvSeYLrl1 9i10+q48eImKu0tAd77hsXTvdsUq6CDsGiEmLx6ePCUhVL4ZUgbgMEgz4MlhBurYOj aBnjSrFQC1+Ng== Date: Sat, 26 Apr 2025 18:25:40 +0000 To: "freebsd-current@freebsd.org" From: Jordan Gordeev Subject: C++ programs fail to build with -fmodules Message-ID: Feedback-ID: 125078299:user:proton X-Pm-Message-ID: d32a150dbba849c357a01cc4178b875f93fbf97a 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-Spamd-Result: default: False [-4.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[proton.me,quarantine]; RWL_MAILSPIKE_EXCELLENT(-0.40)[109.224.244.17:from]; R_SPF_ALLOW(-0.20)[+ip4:109.224.244.0/24:c]; R_DKIM_ALLOW(-0.20)[proton.me:s=protonmail]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29676, ipnet:109.224.244.0/22, country:GB]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[proton.me:+] X-Rspamd-Queue-Id: 4ZlJ6w6DmBz45ZL X-Spamd-Bar: ---- Programs written in C++ fail to build with -fmodules on 15.0-CURRENT if the= y include the headers , , or any other header th= at includes . The flag -fmodules enables a feature known as clang modules. You can read m= ore about that feature here: https://clang.llvm.org/docs/Modules.html On 14.2 building with -fmodules works. I've filed a problem report about the issue: https://bugs.freebsd.org/bugzi= lla/show_bug.cgi?id=3D286342 Anyone who can help with this issue is welcome to do so. Best regards, Jordan Gordeev From nobody Sat Apr 26 22:49:01 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 4ZlPyk5WmHz5tsqG for ; Sat, 26 Apr 2025 22:49:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZlPyk4Y3Lz3c94 for ; Sat, 26 Apr 2025 22:49:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745707742; 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=1frqchwt1IrScY9uQfSDi19Fxibc0W1jxAQHAN70jnM=; b=N51MRM69D1xaquXJoZo5Rv9ai4oOIAPQEa4MyKmp18KfIBnx2W/rqTL4H7lvofP5iDqNbu WIB5ynxv6WgJ+OdtiU+tzS303OE1EGUI5OzrqLAK1SXQsLUHuCnE4ngVAEVUxPjC9NLy+N 5Kc7c7TUq3tQmuKN1/HlbT/zm0p9MtsB+USw3CzaU2RVYA2D2flIvRXgNGKh44PYmA5xmP EK8aZR7eeS+/BdZ0Y+94thDf3JdDNOKMPF/XiZO47nev0OB70u6/Z1Lfml546B9wB3vGBJ eDlx8ni66525M3cTHhpHyY2YprIMZ2AjpCogxE1//ZwbzY/gs/uJ5FrqboT+WA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745707742; a=rsa-sha256; cv=none; b=Q1eoYtL8Me/UGAEUxEZ+3eb2TFpGeV279k+uIIIZtcI1lUyM2DyKCaC2EoqyEIVacIX/NY cLNikaI1uRIbGHZI2OfTgf8OgZIBf4xyzuZnSEu5gIjqxv+gert6vLFpqbh8zKYljhiNXN oFvGqCK8jGS31SuqXN+a14KpAvm1+j/Ki05HSsMeXgGcL81h5xqiHEcCsBwfFWQUnDz5kC tNrXYsDiw0/y9wmFuwD+MZh05oYIkctzt1ZWuU375SnDszh2wIPjes6G7z+9VrSZFuRaya rT/Rvog6ZLZdFdP/b3sAlXV/GnL+QK8ymhLMkUZzI/H6b4mJfuO6HyhmmCOM2Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745707742; 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=1frqchwt1IrScY9uQfSDi19Fxibc0W1jxAQHAN70jnM=; b=E1UYG3q9gzzaaY6JoD2p0oHOyzp+JmaeLzYsFMTzWn9wntfLJBB8F1bQvb84CHjPqrGPbS 9nIOrWTQ+6iHdRr2Vru+bclHEBSJUziYFy5/Tm/GvWuX2JBrNGxi7815MR2dxv0HJryrvF EfkX+6uPo9FcVnnQdUia0d/W6NY8WpUReymU2FNswcf5u698Mt7i2X2Zt4wM19PrfR9JNY bHZCKHxBs5byTABcbnhz8697u8kyfGkXEhkcUy10Hlkn6949N1CKrJ9sWSDVC1iLW1uabM sV88d087F2eUa1dac7d6som19WJ/D/6KPUHp/eS+uC3lQh/pknXn9osWNJzPDQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4ZlPyk3c3czgbk for ; Sat, 26 Apr 2025 22:49:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 53QMn2Ns076631 for ; Sat, 26 Apr 2025 22:49:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 53QMn2A3076630 for current@FreeBSD.org; Sat, 26 Apr 2025 22:49:02 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: current@FreeBSD.org Subject: [Bug 285044] legacy BIOS loader: lua gfx logos on 15-CURRENT are broken Date: Sat, 26 Apr 2025 22:49:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: nxjoseph@protonmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc attachments.created Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285044 Yusuf Yaman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nxjoseph@protonmail.com --- Comment #7 from Yusuf Yaman --- Created attachment 259903 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D259903&action= =3Dedit the wand is closer to menu.webp Hi, I don't know how was it looking before when I use 14.2-RELEASE but i am on 15.0-CURRENT now and the beastie's wand seems to be much closer to the menu= as far as i remember. Sorry if i am wrong but i just wondered. --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Sat Apr 26 23:28: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 4ZlQr24TNBz5twDB for ; Sat, 26 Apr 2025 23:28:18 +0000 (UTC) (envelope-from nxjoseph@protonmail.com) Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch [185.70.43.167]) (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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZlQr21zRvz3r7t for ; Sat, 26 Apr 2025 23:28:18 +0000 (UTC) (envelope-from nxjoseph@protonmail.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1745710095; x=1745969295; bh=kLSa7kZ4ww/HUfNpRPeX7vmBlM9oo7kUvh8xk2igAT4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=LqLAaRPmzi8Xft+znBQWFLpGv2YdlZYQhID42YyzAf7TYNZpHsNqwa4Kn3LmiN/+v Q0bx48DHyeurZ/Ddu4U6oNLZXacIrkvpy/LLs2AkLLb47HkCKkBx082MiT4RAcDfrZ bINznl2agGUqEpAEUOJkEsq0Mp0uYUUrnP71b0IOJp9HXFXoo7+TTDfn1qrYMW+DoW R2ZFdkw2EZLcdwILudliUgsUsaar4OIdj4O7+KsAKeAutHahMsoAA8inYYAtluLSLd qsNrOuz1roxIJ9zFqvR788V4WzeZDizOW00zB4xBnlD4V8E7rbvWKcNVoaSTTlvI7p I8pQ2agMyj91Q== Date: Sat, 26 Apr 2025 23:28:12 +0000 To: Dimitry Andric From: Yusuf Yaman Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries Message-ID: <89541cda-2c5c-40de-a8ec-8474f825dc15@protonmail.com> In-Reply-To: References: Feedback-ID: 21989843:user:proton X-Pm-Message-ID: a0445d6cd958793274eb5cb5758f65028d5ff3b0 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] X-Rspamd-Queue-Id: 4ZlQr21zRvz3r7t X-Spamd-Bar: ---- Hi, I am a new user of 15.0-CURRENT and just updated my source tree and=20 noticed that there are now files to be built that have the ".pico"=20 extension, as a ccache user, i was enjoying fast world/kernel builds but=20 these files doesn't seem to get cached to me and my world builds are=20 taking long time than ever. Is there a way to skip building these=20 ".pico" files? Thanks in advance and thanks for your efforts and work. I am on this commit. 6014596899c On 4/26/25 7:06 PM, Dimitry Andric wrote: > Hi, > > In https://cgit.freebsd.org/src/commit/?id=3D2e47f35be5dc I committed a > change to convert libllvm, libclang, and liblldb into private shared > libraries. This means that tools like clang, lld, lldb, and more are now > quite a bit smaller, as all the common functionality is located in those > shared libraries. > > Note that these shared libraries are not the same as upstream's, and are > _not_ ABI compatible, which is why they are installed as private shared > libraries. If you need ABI compatibility and/or the llvm-config tools, > please use one of the devel/llvm ports. > > This affects the following binaries in the base system (some of them > only exist if they're enabled through various WITH_XXX options): > > - addr2line > - ar > - bugpoint > - c++ > - c++filt > - cc > - clang > - clang++ > - clang-cpp > - clang-format > - cpp > - gcov > - ld.lld > - llc > - lldb > - lldb-server > - lli > - llvm-addr2line > - llvm-ar > - llvm-as > - llvm-bcanalyzer > - llvm-cov > - llvm-cxxdump > - llvm-cxxfilt > - llvm-diff > - llvm-dis > - llvm-dwarfdump > - llvm-dwarfutil > - llvm-dwp > - llvm-extract > - llvm-link > - llvm-lto > - llvm-lto2 > - llvm-mc > - llvm-mca > - llvm-modextract > - llvm-nm > - llvm-objcopy > - llvm-objdump > - llvm-pdbutil > - llvm-profdata > - llvm-ranlib > - llvm-readelf > - llvm-readobj > - llvm-rtdyld > - llvm-size > - llvm-strings > - llvm-strip > - llvm-symbolizer > - llvm-xray > - nm > - objcopy > - objdump > - opt > - ranlib > - readelf > - size > - strings > - strip > > In addition, all these executables are now position independent (PIE). > > Please let me know if you encounter any problems resulting due to this > change, as I intend to MFC it. For example, I tried covering all > incremental build scenarios, but I may have missed some corner case. > > -Dimitry > > From nobody Sun Apr 27 06:46: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 4ZlcZ41Q3wz5vPHW for ; Sun, 27 Apr 2025 06:46:52 +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 4ZlcZ34BhDz41J0; Sun, 27 Apr 2025 06:46:51 +0000 (UTC) (envelope-from 6yearold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-6fead015247so33504807b3.2; Sat, 26 Apr 2025 23:46:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745736410; x=1746341210; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZUjAzFSO6DOxZMmZxEaH+d4VtG9KtQE1nZ1Id/EOe5Q=; b=jhruYThgXtsweAYz4bfgBgQd4xz9P+0EWAbU6rr6jgo8PjfYR7VKMyz+pGfm6UeA29 Vrh9XOIi8mpvAjUOe8jONaLB8sfZVZvUhqHsGoWw53kvYKKQ796lC2zdwCOTKN0i7hDz TmN8osOHaN4k5klJwrNzuphozvD+oNdfI0X7iPzD9vBzArmO4Wkjhy6/BotMf33Dh76k oTTIJs7WbS/93mmf5MNaqdPPxHcX0ekM8o5iar4fx/YPPkJRQNgXmm+oE00ClsTBp4GW BcXCAWiQ5jLetGwEB6Kcdo7Ftc4RDxId6WbN8V2dEK9FDrrc928pzgTKwngak32064T9 e1gA== X-Forwarded-Encrypted: i=1; AJvYcCVL6zQxdyTSyCeYqmREjTnH86c5qfrOyxy3kJnNCRpyfzWJ/1Lv8g4wbPIoTCALrP8l5BVv22fcTdCh+xGAKIo=@freebsd.org X-Gm-Message-State: AOJu0YyjmYcGSJhaxnkJs1cOfHLnsSDEIWT3Lav5VpviQ9uV3X7zOQh7 2Wvf5Bw5TiVw5Cjx03WE/ptiLddrnJ7d4fZnwNRTVNjvEQJ6f1SbMdR4h7cATSQ= X-Gm-Gg: ASbGncs9a4plKQKJTAAotd+OF8iIiKv1Km1/NcfDK7A7RgPtwJTSv49Q53AEq0WcdSW s/Mern0iInXZ+vjB/JgRS2xj7yk3eTFvio7V13wjYqiVhNseb0dROWOuADmVoHILV/WX3FzZu57 0J2gzU3h5qhhoprSXh0ovkPf7sUm84EhyKBCuGSvgld/8FbR39Gqvk8QeKRbWBzOKA9+JZPcxW0 nRJciz6HoiciwH//X8+BhfgFrggJhLEaBhygtNkrmE8lAYtYr1niTEgbv0RVr3EfNAdTHQ4MAg8 ipo8Eg+0g+fcsB5IMorvhG1W/kF9ScWbIIBbeGoxtpFD/WdcZX8C4Tv1oZxNny0S1yDIFEXCj8t h+QUp X-Google-Smtp-Source: AGHT+IHMa3Qc67A7ufHMtvY8KA1wcfgJFSVuCKi4yyDLUslM8TWd6QS36PH/Bo66nSgs02RE/2gEUQ== X-Received: by 2002:a05:690c:4908:b0:708:39f0:e673 with SMTP id 00721157ae682-7085f21de3emr67609507b3.26.1745736410121; Sat, 26 Apr 2025 23:46:50 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id 00721157ae682-70841acdfc5sm17885737b3.79.2025.04.26.23.46.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Apr 2025 23:46:49 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-e461015fbd4so3159894276.2; Sat, 26 Apr 2025 23:46:49 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCX0QHNU58jdkKhCVw6H+Y2p372J/83wutB4CJF44BnujIdUlWpY7HnRM0elZCGYU4dju3wybCD5x+bWEZuSWE8=@freebsd.org X-Received: by 2002:a05:6902:e01:b0:e72:e0c4:fbb6 with SMTP id 3f1490d57ef6-e732347aac5mr5799999276.42.1745736409705; Sat, 26 Apr 2025 23:46:49 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <89541cda-2c5c-40de-a8ec-8474f825dc15@protonmail.com> In-Reply-To: <89541cda-2c5c-40de-a8ec-8474f825dc15@protonmail.com> From: Gleb Popov Date: Sun, 27 Apr 2025 09:46:21 +0300 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUGHpOGsDtR2XzxKqmCDwLoE_Ks4O9-gD1TOBr7SXhNlQ7BCDcolMdjMtMc Message-ID: Subject: Re: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries To: Yusuf Yaman Cc: Dimitry Andric , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4ZlcZ34BhDz41J0 X-Spamd-Bar: ---- On Sun, Apr 27, 2025 at 2:28=E2=80=AFAM Yusuf Yaman wrote: > > Hi, > > I am a new user of 15.0-CURRENT and just updated my source tree and > noticed that there are now files to be built that have the ".pico" > extension, as a ccache user, i was enjoying fast world/kernel builds but > these files doesn't seem to get cached to me and my world builds are > taking long time than ever. Is there a way to skip building these > ".pico" files? Maybe it is ccache that needs to be fixed to handle .pico? I remember reporting a similar issue to gllvm [1] and it got fixed. [1] https://github.com/SRI-CSL/gllvm/issues/41#issuecomment-718875683 From nobody Sun Apr 27 09:52: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 4Zlhhp4JCHz5tbWT for ; Sun, 27 Apr 2025 09:52:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zlhhp0brwz3ZDG; Sun, 27 Apr 2025 09:52:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745747578; 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=gr5Lm3JOHVDNzuRjFsuOh6+uRTjG7cxnsfaFMS3P1kA=; b=YObl2rPWq7qKBsAtgTpMZBry3A2vxv6eXmmHTPc7Z+CED2A+3GD9PW93ZHnQ8CblRA11vm C1ID0vaTdSMJn41xWjrjnq/F6QtbM+8qzRAKVKGbK1LvRolxkw3/QAxHvXNlsTTNFdER0z 5rtk0iNDwbb6/rhDqLU9siskaENUBcyLVxOdMjADYf+WpuJU2Mj+5xqthgusCdrQVVE+Or gZNAs2dtTNqYBzEC7wfzzCh4YV199deK1tv+uSP+j+IWDs8HpQo9GVSG4wWF/QlSRRatR4 w2TJL3RLIxqHX2k5Sr8YYIKzZP7MDkint3xKviUafrVlkGawvOXGoT7eyUJWGQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745747578; a=rsa-sha256; cv=none; b=GG/suUjVRjZdqTJQHlf23KXPIwWf7esPl+KvKhptsM5QmqoRotL0N7WyQOK67+PvO2lkRA DWZgmBofk4xZjKfFXq+zFX3eqPJgcCcEdnRWbjv9MgA4qaw1/t4ayHnaxY4Gxs3AJeZiEn qj69UpZ/hMyMOqseYBVU5D3SzDFchjJ0Ha7O00QLO+qeeeUI/vV99bS1TH06BJ9LVWQV7u fBps7eHWj+uP9/3qSew0K6GcnzVXyJbhTfpq27FE1D3rSKYH6NdxCfqTYBMHq3G+ji/WmG 4l8agYzSvNPVxkcpvJKOp3ClCyyRfYe58I5ovs/VjXqCmByAjamBHH0NwT6lfw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745747578; 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=gr5Lm3JOHVDNzuRjFsuOh6+uRTjG7cxnsfaFMS3P1kA=; b=qvEkpD4R+3cnM82/uJS8IhlF+hfY3h1DA8HsSDnnTD7MO/n08TNgtys2Y3UVcgnG49DAMc XIcaFKmSyJ4+AEOW5K6IsKPuOg8HRWddB3bpoTaUEMAVnXHGVruFXHIXNC0WJV2uynurIv Wq4R8jkMQeQ3Wcv0w5UQgAgHTflKpml8DKMu2okk7f/nYrteHIeE//+l7FoEzh+5uaRDNg NByuyjsL3zsLsCITMKl0jCv3yCyqbdlG+G2VSoFpJrf48wMEml3OQc2vmu3V44v73FJvBU sT/Cktwf+jSOyXKZkdEdelQCH3ayDq3c36EuYgZ94a1/zRuGS7TCJnik9m4K7w== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R11" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zlhhn4lJHzClY; Sun, 27 Apr 2025 09:52:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 70285411FC; Sun, 27 Apr 2025 11:52:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.10\)) Subject: Re: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries From: Dimitry Andric In-Reply-To: <89541cda-2c5c-40de-a8ec-8474f825dc15@protonmail.com> Date: Sun, 27 Apr 2025 11:52:56 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <217084C0-1D22-4BD1-B9DF-ADB815B48FE4@FreeBSD.org> References: <89541cda-2c5c-40de-a8ec-8474f825dc15@protonmail.com> To: Yusuf Yaman X-Mailer: Apple Mail (2.3731.700.6.1.10) On 27 Apr 2025, at 01:28, Yusuf Yaman wrote: > > I am a new user of 15.0-CURRENT and just updated my source tree and > noticed that there are now files to be built that have the ".pico" > extension, as a ccache user, i was enjoying fast world/kernel builds but > these files doesn't seem to get cached to me and my world builds are > taking long time than ever. Is there a way to skip building these > ".pico" files? Thanks in advance and thanks for your efforts and work. > > I am on this commit. 6014596899c We have been using .pico files for years now, so that shouldn't really a be a problem. At least, I hope not! However, if you did an incremental build, previously libllvm and friends were built from .o files (i.e. position dependent). These were then added to a static library, with a .a extension. Now libllvm and friends are built as shared libraries, therefore all the objects have to rebuilt as position independent (PIC), with a .pico extension. Similarly, a number of tools built under usr.bin/clang have been switched to position independent (PIE), therefore their objects also have to be rebuilt: instead of .o, these now use .pieo. In any case, ccache will still help if you do future rebuilds. It is only with this particular transition that a number of objects really have to be fully recompiled. -Dimitry From nobody Sun Apr 27 14:26:13 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 4ZlpmC3YKXz5tvQX for ; Sun, 27 Apr 2025 14:26:19 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 4ZlpmB1Rrnz40ND; Sun, 27 Apr 2025 14:26:18 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=UFj+2xnz; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::82b as permitted sender) smtp.mailfrom=markjdb@gmail.com Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-47692b9d059so73519701cf.3; Sun, 27 Apr 2025 07:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745763976; x=1746368776; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=o6B1uoATUg+QytFpdUhm+vjHd0Da0O5DRdhEtkBm2Wg=; b=UFj+2xnzeMkjBV5rhFaz1pk15KhUKNOugc9Dv+BRUk9MbwyeXS76S8fkFbXATPQ8zu zSSwdAAEw5DMH23/JHBdkkxH83GlwDicGNw0kbHeZeI6rAggJrQFkO0AS/icALL07X+z sUh7yuvM/Q6ASUy60LxOO/PLIIqRpnUVTNsVVFd9tSyDCmgyA1gIGCJS0GoUj+652Z9g tKiccZ6qmMpiCsmdHpAMwTTwIRLL+tXpkWi5zWy3ARgFxatupPlK4Nazt2l0pGZntBAw VZFA1Af1/mzDUzoO2kOuxOGOsrNsjLb9JHW0dXm6IjbV/8LkAtXsVA5O714qTBFsKhOp Y1/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745763976; x=1746368776; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=o6B1uoATUg+QytFpdUhm+vjHd0Da0O5DRdhEtkBm2Wg=; b=jdt5hV+pK3Q1AMbEpI9fBRVw5vu3jKL4FiyQI37MgzTpOgZ40VOwywKNNPJQk3u/RB kmBYcjueqR2nkNXVqsVcCrojsH1qfI6ii0N4MHpds7ogkdCAfhtqEiYv3nnHV5cH8gKF hMZe5iKBK9t0A04P5dTXjub3L3WjZ6PVBXpUCzK4OfPMQldFENAE1sG1SRkTuWX2aa3g 00niqy8i0ZonBl2fVNus4/Z+C3m+qybbQeBiDAmzHT+9mPlU7OxQlJn+JsUleUky5DUD LJHvutcP1ROgOEj6kDUm/cHEHwlRccXhjJy6UrRcmo1Uwrsw9hSzUrIhWExWZB6tMoUv C4jQ== X-Forwarded-Encrypted: i=1; AJvYcCVr3SLwBPq0gO+w68A1sZr7GeS2onmwDe7GbM9EGdq2Ga4gmqS/tUUfpyhqaorFR5UyN3gGjFwM@freebsd.org X-Gm-Message-State: AOJu0YzTNt+/NG0hMyEtRlUW+tHwVPgyG9Q1hRnMzVf+j1NWx9KY3RX5 dTFV0K7giIeO4sokEMUgh63gtolmc6JO4Gd+cHvr/rDXyB6nrmWKFUGeM/er X-Gm-Gg: ASbGnctRaB8UzYT95nIupIt/k8xBwZ8h9cLvWd/hzlxbW93CmGb6rB6AOo0vlO+5dZJ iouRz9VjF7vPKbh7EP66R1Eum/jReZZLCXOdr3fb4vyPKUs85dm28ixQ5IMbV2xc4E74nAjuIm9 ENh7oQ5LrW8v5gL7jemOsFwGtNWu1EesSROSuqMpKDnAoavTP01K0H3lwJHfQlnMKiE61WqVSz8 Qj6cuM+btSH1jQtSiqcUf4bf1C5gphlmcZhB9NQkKJIemubxVxFVZEc8qBnj8HKSPCv4WmVeg0+ kg5sr0LsjtJFn+n1WRj01fbFTp+M8JpzmBxGB2zWYRsLcyn5I3hn2yE= X-Google-Smtp-Source: AGHT+IFmk+97cZi2wChF6hudKeMmRhRbMCsYz4s5jcvo9xwWiTfYW1hNV58FggoO2Ri+CKfacA/GRw== X-Received: by 2002:a05:622a:3cc:b0:477:4df:9a58 with SMTP id d75a77b69052e-48131903d5dmr100440541cf.18.1745763976216; Sun, 27 Apr 2025 07:26:16 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-47ea1794482sm50036181cf.56.2025.04.27.07.26.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Apr 2025 07:26:15 -0700 (PDT) Date: Sun, 27 Apr 2025 10:26:13 -0400 From: Mark Johnston To: Andriy Gapon Cc: Konstantin Belousov , FreeBSD Current Subject: Re: RTLD_DEEPBIND question Message-ID: References: <0b3dda4e-53e4-40e5-9484-8b5ffb84e658@FreeBSD.org> <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> <59db8ace-770f-4f73-976f-411f6de0885a@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59db8ace-770f-4f73-976f-411f6de0885a@FreeBSD.org> X-Spamd-Result: default: False [2.74 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.68)[0.683]; NEURAL_SPAM_SHORT(0.65)[0.653]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82b:from]; MLMMJ_DEST(0.00)[current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZlpmB1Rrnz40ND X-Spamd-Bar: ++ On Thu, Apr 24, 2025 at 08:56:44AM +0300, Andriy Gapon wrote: > On 23/04/2025 21:56, Andriy Gapon wrote: > > BTW, I've been wondering how illumos avoids the problem even though they > > do not use any special dlopen flags. > > It turns out that they link almost all system shared libraries with > > -Bdirect option (which is Solaris/illumos specific). > > It's somewhat similar to, but different from, -Bsymbolic. > > https://docs.oracle.com/cd/E23824_01/html/819-0690/aehzq.html#scrolltoc > > https://docs.oracle.com/cd/E36784_01/html/E36857/gejfe.html > > Oh, and it looks like there is an even better explanation for illumos. > There is a version map file for libdtrace which explicitly lists API > functions and makes everything else local. > https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libdtrace/common/mapfile-vers > > I wonder why we didn't do the same when porting. > Maybe we should do that now? I don't have any objection, but I believe adding a version map after the fact doesn't accomplish much, assuming that we care deeply about ABI stability in libdtrace.so (I'm not sure we do though). > > I think that on FreeBSD we should use symbol visibility attributes or a > > symbol map to hide (make local) symbols that are not expected to be > > interposed or have a high chance to be interposed by accident. > > > > IMO, yyparse should definitely get that treatment. > > > > I think that approach would be better than magic rtld tricks. > > Especially because the tricks do not work with the current rtld. > > I'd rather make a change to libdtrace.so than to rtld. > > This, while not as nice as the illumos solution, fixes my specific issue: > diff --git a/cddl/lib/libdtrace/Makefile b/cddl/lib/libdtrace/Makefile > index d086fffb07bc..58054d129b49 100644 > --- a/cddl/lib/libdtrace/Makefile > +++ b/cddl/lib/libdtrace/Makefile > @@ -146,7 +146,8 @@ CFLAGS+= -fsanitize=address -fsanitize=undefined > LDFLAGS+= -fsanitize=address -fsanitize=undefined > .endif > > -LIBADD= ctf elf proc pthread rtld_db xo > +VERSION_MAP= ${.CURDIR}/Symbol.map > +LIBADD= ctf elf proc pthread rtld_db xo > > CLEANFILES= dt_errtags.c dt_names.c > > diff --git a/cddl/lib/libdtrace/Symbol.map b/cddl/lib/libdtrace/Symbol.map > new file mode 100644 > index 000000000000..89ee9de65209 > --- /dev/null > +++ b/cddl/lib/libdtrace/Symbol.map > @@ -0,0 +1,4 @@ > +{ > + local: > + yy*; > +}; This just gives the lexer/parser symbols in libdtrace.so local visibility? I think that's fine. From nobody Sun Apr 27 15:04: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 4Zlqbz2v6rz5txCf for ; Sun, 27 Apr 2025 15:04:15 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 4Zlqby55TPz3Mkv for ; Sun, 27 Apr 2025 15:04:14 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-xd29.google.com with SMTP id ca18e2360f4ac-85b41281b50so130654639f.3 for ; Sun, 27 Apr 2025 08:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1745766253; x=1746371053; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=oMsJcCJc7NW/tYl37kzmDlrb3fIeDNaI/NL1OtkAHOY=; b=an66t+nctgBofJDB83CRovEqdaDIfCTWXaH4PsFKNfKmDDnvn69BzSIGMePnmaseVP DOKYQ88CwecKpgXMZAZnXPOrkHy2V/lHXNfmxIyuJn9TaK/uO7MowWPmFlvAcxkRSfqM cL0R85stvBU85S2C662tzpVz03XeYw1CVvX+CxXIJux+nZ8GAVuTSUARJE/YVQUxQ6w+ +byCm3j2KxSZDpqfwV20fGjvHiPwkI+cpBHTWVhagM/EmHBCaL2Nv+1ytC9UiUJ34MAg HqK+rjAImwOcpuh5GjbW6w0ZcDzZyExucNmMxXpbW2lJ76DlEq1OiirKyegsNc/di6Jz f7dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745766253; x=1746371053; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oMsJcCJc7NW/tYl37kzmDlrb3fIeDNaI/NL1OtkAHOY=; b=eLfpbWw4YPFQOUDFoYUG86c2yXg3Pfyu2XGNE0ePqS8ZZjiDMcuEOlbb94609CscmH COxjH+XeUoZyanWxqaSvtprkPgEEP+k3xeeraXzGKNM6boS8mKO9ZBYMhXGjVcJToBW3 AYBrzTfGt3x6dqHb1BnvB2FG0EpuxDg4A2dvlwtC6MQ4QUBiJ2znKzY+5eKDJxH7aY4l GtJMkX2zvlKVSXYPPHPIXJUAeur0rt/xhR1U9iutGnnZXNA/xx/eMp5miUmaCRh5SyMx g43r6NooLW444Vm4unn71bIwFpCdCq253BasA7Z0JwLzgVixBWXReBtpR4DjwWfi038+ 2TtA== X-Gm-Message-State: AOJu0YyfDwygalnY9Za72sfQQRKFvCTyNYDBorTnXJ8PDW1jACTY1RDp Yn9bN9bKQI/N4bh7mbmuvJy5rTRgBn+exwRUPEY5gZLndqQbWP1wiGjIUDGpq6I= X-Gm-Gg: ASbGncsBPNC0OAbzBhtBiJIgtR7e0rGrhAiaOLwZiN7YzWlEg3ohcFkDgzPcgqK3Z67 SOjFX90QMBgw+0Y6jqqysn6lmCxW7/xIJqfrT/pvqgz6Scjv2PgxQxWMIZNUqSdaAaKKNiayDgz jQGyFpcsMl1jo66HvYN88bc7wWKHjpRZfDeYJWou/R9urNGV3ZfZU+zulMduXhrSr1HbNCpeD7A zouPjHAgLJ4kiXJHbO0nS1XbPhAx+O2V6eKPq6nRhApF+0xBQTut7lP9cjoihIoaqed6Q6Z1TKW 7MZTOOuCrW0njj+wfAikjRE= X-Google-Smtp-Source: AGHT+IHp9uXIlI9sPMRahq7LxDZ8y/gIdA9af7xxJum5E51pfx2C7PHWQPO3Z/Wa4D1/ObhQ3xLXsA== X-Received: by 2002:a92:ca0c:0:b0:3d5:81aa:4d0a with SMTP id e9e14a558f8ab-3d93b4188cbmr81505945ab.6.1745766253525; Sun, 27 Apr 2025 08:04:13 -0700 (PDT) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3d93159f655sm15561215ab.52.2025.04.27.08.04.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Apr 2025 08:04:12 -0700 (PDT) Date: Sun, 27 Apr 2025 15:04:11 +0000 From: Shawn Webb To: Dimitry Andric Cc: FreeBSD CURRENT Subject: Re: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.2-STABLE-HBSD FreeBSD 14.2-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cfgnckxuhnt3e3wd" Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Zlqby55TPz3Mkv X-Spamd-Bar: ---- --cfgnckxuhnt3e3wd Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries MIME-Version: 1.0 On Sat, Apr 26, 2025 at 06:06:54PM +0200, Dimitry Andric wrote: > Hi, >=20 > In https://cgit.freebsd.org/src/commit/?id=3D2e47f35be5dc I committed a > change to convert libllvm, libclang, and liblldb into private shared > libraries. This means that tools like clang, lld, lldb, and more are now > quite a bit smaller, as all the common functionality is located in those > shared libraries. >=20 > Note that these shared libraries are not the same as upstream's, and are > _not_ ABI compatible, which is why they are installed as private shared > libraries. If you need ABI compatibility and/or the llvm-config tools, > please use one of the devel/llvm ports. >=20 > This affects the following binaries in the base system (some of them > only exist if they're enabled through various WITH_XXX options): >=20 > - addr2line > - ar > - bugpoint > - c++ > - c++filt > - cc > - clang > - clang++ > - clang-cpp > - clang-format > - cpp > - gcov > - ld.lld > - llc > - lldb > - lldb-server > - lli > - llvm-addr2line > - llvm-ar > - llvm-as > - llvm-bcanalyzer > - llvm-cov > - llvm-cxxdump > - llvm-cxxfilt > - llvm-diff > - llvm-dis > - llvm-dwarfdump > - llvm-dwarfutil > - llvm-dwp > - llvm-extract > - llvm-link > - llvm-lto > - llvm-lto2 > - llvm-mc > - llvm-mca > - llvm-modextract > - llvm-nm > - llvm-objcopy > - llvm-objdump > - llvm-pdbutil > - llvm-profdata > - llvm-ranlib > - llvm-readelf > - llvm-readobj > - llvm-rtdyld > - llvm-size > - llvm-strings > - llvm-strip > - llvm-symbolizer > - llvm-xray > - nm > - objcopy > - objdump > - opt > - ranlib > - readelf > - size > - strings > - strip >=20 > In addition, all these executables are now position independent (PIE). >=20 > Please let me know if you encounter any problems resulting due to this > change, as I intend to MFC it. For example, I tried covering all > incremental build scenarios, but I may have missed some corner case. Hey Dimitry, I suspect this may be a problem specific to HardenedBSD, but it looks like cc occasionally crashes. It hits an assert at /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:2702. I can reproduce this by running `env SHELL=3D/bin/sh make buildenv` at the top of /usr/src. Though, it doesn't reproduce 100%, but perhaps around 60%. =3D=3D=3D=3D BEGIN BACKTRACE =3D=3D=3D=3D hbsd-current-01[shawn]:/usr/src $ lldb /usr/bin/cc -c /usr/obj/usr/src/amd6= 4.amd64/cc.core [8:53:37] (lldb) target create "/usr/bin/cc" --core "/usr/obj/usr/src/amd64.amd64/cc.= core" Core file '/usr/obj/usr/src/amd64.amd64/cc.core' (x86_64) was loaded. (lldb) bt * thread #1, name =3D 'cc', stop reason =3D signal SIGABRT * frame #0: 0x000004c0ae52854a libsys.so.7`__sys_thr_kill at thr_kill.S:4 frame #1: 0x000004c0a9751bdc libc.so.7`__raise(s=3D6) at raise.c:48:10 frame #2: 0x000004c0a98177f4 libc.so.7`abort at abort.c:73:8 frame #3: 0x000004c0a97326c1 libc.so.7`__assert(func=3D, f= ile=3D, line=3D, failedexpr=3D) at a= ssert.c:47:2 frame #4: 0x000004c0ac698e70 libprivateclang.so.19`::BuildInputs() at D= river.cpp:2702:13 frame #5: 0x000004c0ac69e536 libprivateclang.so.19`::generateCompilatio= nDiagnostics() at Driver.cpp:1744:3 frame #6: 0x0000013704d7961f cc`::maybeGenerateCompilationDiagnostics()= at Driver.h:577:5 frame #7: 0x0000013704d781f8 cc`::clang_main() at driver.cpp:426:15 frame #8: 0x0000013704d763aa cc`main at clang-driver.cpp:17:10 frame #9: 0x000004c0a9722d70 libc.so.7`__libc_start1(argc=3D3, argv=3D0= x000079004f9a3608, env=3D0x000079004f9a3628, cleanup=3D, mainX= =3D(cc`main at clang-driver.cpp:15)) at libc_start1.c:172:7 frame #10: 0x0000013704d674f1 cc`_start at crt1_s.S:80 =3D=3D=3D=3D END BACKTRACE =3D=3D=3D=3D If you have any initial thoughts, please let me know. I'm not well-versed in llvm's internals. I'm also unsure why `make buildenv` would cause `cc` to run, so that's another gap of knowledge I need to fill. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --cfgnckxuhnt3e3wd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmgOR1wACgkQ/y5nonf4 4fpfww/7Bamc/A+CtSLfKrIKugFaL9iGRvZ2BZPOeeiMLQvuurpMJEAyqhfbOEAP 8NDGJzEadLLCSZXQ99+UVOH5/6zsnfE+I9dDkAVR4T72Ono1S+gDdM0AczHvMhDF uMockk9XSCc+28Uzx4au/ZwrtD/attdM/Ze/XX8uDAl+U+y+X6AGN82CgSeCyhUV cLzxg+RXV3uypfKUedfdHI/k7mUFbG/gnUQg5Di9yi7dWuKbBWhh/dYarMzBs/4n sj9wDxtf6+qJT+j1ZGQiwY52427WAXeZP2P9xv3CDwZRvfg7/smmEwHQUxaYR7Sw f24BXGHi4xPPfwbRtOYE2r/Ihxd2v34xNgyQ3Ub9rhMOrHvcvaXVprOQYmtGEYVp Bgla3w6ggitVZoqoivI+/F0aiSO6Ic0Tz6AZnRC9v05FstvxURHlvzDTgYTuahrq PJt8kHFlHYcS276AjjiNhQJUv/fpabYEFcZ4sGkn5jg2REpDSFAuJeo5wmbC9ebX UFPYZEynuatKw2OZXtYINEKsOm2VmMNQSbkT83h8cI47SmTjKo4cwcDFhdiQ3+EP RFTexPLpZDA+veNyYzjy+jQ5AyuxXRnk6DfGSwSQaDcuCNA2wpIcPhUDFpVJTYyk db66Th3ElvS2JRhGIBqsQ8g92RzWXW3msvOvil5KMNWKAiCBhM0= =5iRP -----END PGP SIGNATURE----- --cfgnckxuhnt3e3wd-- From nobody Sun Apr 27 15:38: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 4ZlrNG4t7tz5v06h for ; Sun, 27 Apr 2025 15:39:10 +0000 (UTC) (envelope-from dch@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZlrNG1cbmz3lY8; Sun, 27 Apr 2025 15:39:10 +0000 (UTC) (envelope-from dch@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745768350; 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=aYcVR0W6YMmK6q628jY5cP+n3wkd3fWuOdSMnf2V5uc=; b=ZB1zlA6DjLfW20Otsp44Xg5b4K7nxzpSsRdqNRGI7e+XCdyWLDCZf1g9+X6lELqqFspRWA 2wVP6C/p5FLyqoeAsfH/sK9LLLom+YMNIZzRFoqnAjNd7Bt9El2pnFVK+is+V7syNLOoKJ NS5zkUaaSrUIaa1L1E20Qv1aRtUmmj5AaFAlwvOVl3RoOv59wuA5dKb30tTMI9pNDJS0mu 7pSRtcQ5ZHe1ObEcQGBoVZbxsHJFQZRixqOYMURlrDy4OojrhckEw1H7cz9nHgJbY7nC1n g8CtbdclwtBKgsJ0ibvPhByuQpanmnxIlpyRAdK7VMzwd9gWUkuW8BObx7U8CA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745768350; a=rsa-sha256; cv=none; b=dDu8SSWoCTtvH/qmhDo0cAvO4IkLRHWeMNNi/bEv2YswBHq6oXwaUA+mktAtovP1g0Cdf+ w1OuxHXhNIxOY5A+e3hnPxH8qwbxeHb+43CTW1eLqfMpy9GF679ppIi3o4DPfqtqYO8sZf UKkK179sE/DHidOBqfE+i0MjBpZ5mmTgl92cLMvnIMBryIvzxoswAtPXRo1FWWDN5o/d1U PKAosYYNnsCe3KI1eFK4ROVsmuXd0Gds0yo4dIrTTb6SgR6wy/PVwn2b//x5TvNUQhKIbE pZDlSuWA2NOUCA9G4zGrYLvQ3jVOr9bcBaDbPPfjLcvui9AQmpnT6T5pPx6Tyw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745768350; 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=aYcVR0W6YMmK6q628jY5cP+n3wkd3fWuOdSMnf2V5uc=; b=f8Rb9LB7KHan/qLcY2HX0JeLbcgyZZ2ZBuULunS2AeuRNTUJ6WmxAzRDLlk0DwQo50Y8dr qLMrbizcEtCQI7rfi01HNlns0VtzHRBb6kfoQVk1TeLvG71XHP2bRhIv8NQ4FajFqhcOki CNcrrhtaJdi7ov30uUd5QAWT7mRKkDEPDc+gYXo+GjOGtqHaEUYoOJ+N3xwsodWlwPVBCw nM40NMx2uby2imFm8QBeCQPITzu1Mo8aFrAsba2ph09xo/Emi6Z4eIxx2P+5hRKMJtbqDd k7tLtynKEmnVd7M5D5Uf3Yw6/g1Fdn3SnYa9fjPkC2hRk5vIYa1f9XxtEUBW4A== Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com [103.168.172.200]) (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: dch/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZlrNG0nBKzLn3; Sun, 27 Apr 2025 15:39:10 +0000 (UTC) (envelope-from dch@FreeBSD.org) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfauth.phl.internal (Postfix) with ESMTP id 683E1120007C; Sun, 27 Apr 2025 11:39:06 -0400 (EDT) Received: from phl-imap-16 ([10.202.2.88]) by phl-compute-02.internal (MEProxy); Sun, 27 Apr 2025 11:39:06 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvheekgeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvvefkjghfufgtgfesthhqredtredtjeenucfhrhhomhepfdffrghvvgcuvehothht lhgvhhhusggvrhdfuceouggthheshfhrvggvuefuffdrohhrgheqnecuggftrfgrthhtvg hrnhepfeekfedttdevheefffevudevtdeuiefffefhjeejveegvdegtdffieduteehvedu necuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepuggthhdomhgvshhmthhprghuthhhphgvrhhs ohhnrghlihhthidquddvgeeluddtfeeguddquddvudefuddujeejqdgutghhpeephfhrvg gvuefuffdrohhrghesfhgrshhtmhgrihhlrdhfmhdpnhgspghrtghpthhtohepfedpmhho uggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfh hrvggvsghsugdrohhrghdprhgtphhtthhopehglhgvsghiuhhssehfrhgvvggsshgurdho rhhgpdhrtghpthhtohepfihulhhfsehfrhgvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: icedc46df:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 41E072CC006B; Sun, 27 Apr 2025 11:39:06 -0400 (EDT) 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: T7d8fb190958b0cc3 Date: Sun, 27 Apr 2025 15:38:46 +0000 From: "Dave Cottlehuber" To: "Vladimir Kondratyev" Cc: freebsd-current , "Gleb Smirnoff" Message-Id: In-Reply-To: <7c4e115c-f0a5-4462-a34f-38291770aa92@FreeBSD.org> References: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> <4aad4a70-a953-458b-ac37-675b6901f28c@app.fastmail.com> <7c4e115c-f0a5-4462-a34f-38291770aa92@FreeBSD.org> Subject: Re: April 2025 stabilization week Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 26 Apr 2025, at 16:19, Vladimir Kondratyev wrote: > On 4/24/25 21:46, Gleb Smirnoff wrote: >> On Thu, Apr 24, 2025 at 05:48:46PM +0000, Dave Cottlehuber wrote: >> D> On Thu, 24 Apr 2025, at 17:31, Gleb Smirnoff wrote: >> D> > D> This issue actually came up last month but I had no time to >> D> > investigate >> D> > D> then, details >> D> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D286045 >> D> > >> D> > Is this regression since last stabweek or from an earlier point? >> D> >> D> Just since March stabweek. >>=20 >> There were no changes to the driver :( >>=20 >> Any chance you can make a bisect? >>=20 > > I think it is regression from daa098cc37b9 > > Test this patch: > > diff --git a/sys/dev/iicbus/iichid.c b/sys/dev/iicbus/iichid.c > index eeabf817616..d82beb52d58 100644 > --- a/sys/dev/iicbus/iichid.c > +++ b/sys/dev/iicbus/iichid.c > @@ -630,7 +630,7 @@ iichid_intr(void *context) > error =3D iichid_cmd_read(sc, sc->intr_buf, sc->intr_bufsize, &actu= al); > THREAD_NO_SLEEPING(); > if (error =3D=3D 0) { > - if (sc->power_on) { > + if (sc->power_on && sc->open) { > if (actual !=3D 0) > sc->intr_handler(sc->intr_ctx, sc->intr_buf, > actual); > --=20 > WBR > Vladimir Kondratyev \o/ works perfectly, thanks Vladimir!=20 A+ Dave =E2=80=94=E2=80=94=E2=80=94 O for a muse of fire, that would ascend the brightest heaven of inventio= n! From nobody Sun Apr 27 16:57: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 4Zlt6N53GSz5v4MZ for ; Sun, 27 Apr 2025 16:57:16 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zlt6N0qZwz3WTV; Sun, 27 Apr 2025 16:57:16 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745773036; 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=H5nPIdNRylFqfVyjBOGGOmcQXUYtPfntxixbta01Blg=; b=Ela+rUvbgpOex9yEJuOy1kc/3P7dOAFx/O6N/Y7psCZgxojY3ySJnoUKNaQvGjWid3TbUO nVJuOPPGLtXBMR9ddIGp9nzz8RYZXPzJNMvl3qediRGF3ppxEEZpiBrjdIg9oyOjumIAhM va8FX7CUdPm0tneAj457z8IyTAnFoqgKvbP/3g3UYe4tZ+qhx3yfDmR+lZl8r5k622R1lr r3aXw2UkLssd+qR+5jYitL4MMbbqJpsftDCESYx5ZpcUi2148A4LaODeIJT60Lcnfm32Wx 6Olu38qre86WsoSSBCA66LebpaEa0pbDFO9JSGKSKKmewwLawvfFOBRIz8iLlA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745773036; a=rsa-sha256; cv=none; b=WHoKkxjsIlQRnE+vX290E/WDM1M1kbu4MSygwwY66FFIzRH1d9q//rXLS+79YN1MXyRlgY eQd5rsFK/v400rEfFEnvzMIL5pjQz7Bw2GdkNHaNhVQnui9rsKWMdmq84fJyeEibFugHT5 S/LGLyyMFhTPVrsgN5QfeaiKNk+pgaLIh2nAlN72Q+cG1zL/mNk62OW7iJsXJavUpZWk1k o+vINX0KDgFsEx6Wii6AkIrtL6jwoFtN0JiNQizVJi2UaaGaY31e+58ivNU8wUnKmsbWZB XLcwmPVP9sC7TeXRlmjmrDy16zc3qWmCCzqjNLtW+8Fuk+YJcFUG/2Rq24Ifbg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745773036; 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=H5nPIdNRylFqfVyjBOGGOmcQXUYtPfntxixbta01Blg=; b=RUtNC939fiLCK3CI2htFKCoZoLFVyQr8q52RcF090/S9EddBpWoulvojHXDqtL8K2kx/nt KuqrOqV1lTSFjQAK0BSHIU/CXgR2oQiB3aqZnlniK61rbxzgHIn8bIasEYLt9zby8T1/T2 PryqbCYo54hwHJ2MaCXk63Q0iB9yU7oacENS9Fy0mFsCyUFJkqqr4SMG0qvGoovpJFZaqI +sIpDQO2oV1U4XMjLFgGJCMhiRRHOQ/QT8wTIjFKF5qMwgY+rkSbUNUj1g6SfC6xcz/T3z 8dufnhAHZ3DIh0kRtIUxICtjpGB0EUruoDWczXSvquNZi/Qe9JNu/R7bhQWqgA== 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 4Zlt6M42dMzMRv; Sun, 27 Apr 2025 16:57:15 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Sun, 27 Apr 2025 09:57:12 -0700 From: Gleb Smirnoff To: Dave Cottlehuber Cc: Vladimir Kondratyev , freebsd-current Subject: Re: April 2025 stabilization week Message-ID: References: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> <4aad4a70-a953-458b-ac37-675b6901f28c@app.fastmail.com> <7c4e115c-f0a5-4462-a34f-38291770aa92@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Apr 27, 2025 at 03:38:46PM +0000, Dave Cottlehuber wrote: D> On Sat, 26 Apr 2025, at 16:19, Vladimir Kondratyev wrote: D> > On 4/24/25 21:46, Gleb Smirnoff wrote: D> >> On Thu, Apr 24, 2025 at 05:48:46PM +0000, Dave Cottlehuber wrote: D> >> D> On Thu, 24 Apr 2025, at 17:31, Gleb Smirnoff wrote: D> >> D> > D> This issue actually came up last month but I had no time to D> >> D> > investigate D> >> D> > D> then, details D> >> D> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286045 D> >> D> > D> >> D> > Is this regression since last stabweek or from an earlier point? D> >> D> D> >> D> Just since March stabweek. D> >> D> >> There were no changes to the driver :( D> >> D> >> Any chance you can make a bisect? D> >> D> > D> > I think it is regression from daa098cc37b9 Great that the problem has been solved, but there is still an inconsistency. Dave says this was a regression since March stabweek. But the daa098cc37b9 was already there. -- Gleb Smirnoff From nobody Sun Apr 27 17:04: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 4ZltHG5Wqbz5v4lq for ; Sun, 27 Apr 2025 17:04:58 +0000 (UTC) (envelope-from nxjoseph@protonmail.com) Received: from mail-24427.protonmail.ch (mail-24427.protonmail.ch [109.224.244.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZltHG29zQz3c8d; Sun, 27 Apr 2025 17:04:58 +0000 (UTC) (envelope-from nxjoseph@protonmail.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1745773495; x=1746032695; bh=qNDD49masVjea+49vp5QDaJh6BiFtA9ApdCQwUP9vDw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=mzusVGb+U0c91KTU2pfeSdr8pQjRUsOPRCo3FzkE8ZEM4RG6ttNyM9/n0akmmcik2 CVwdPdKwiZxnknSLH6bud9gqbnP/Dgj8PM9xS9Ow7tmYOk3JT6w6Z/mtlsIj1InRAG /TXGuto+qTF8fm1MrsfiA9KdBQ2LIv3sP83tMTrJQu3qFiwC9zbMc+RuS1vXfXbhkF 1G6g3TV96jLjZwEgW8MZAXkYYroaSSXsz0Aj66MkBAtbcMLSvTzRG5ic1mUQ5guryF ZDsaRxQaLN+Q0AsIJC7cLnae5OuSbMFiK9nj6qQVrHLUPU3XC+sCAPir+Ghfm80ytj d12ao90175sXQ== Date: Sun, 27 Apr 2025 17:04:52 +0000 To: Dimitry Andric , Gleb Popov From: Yusuf Yaman Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries Message-ID: In-Reply-To: <217084C0-1D22-4BD1-B9DF-ADB815B48FE4@FreeBSD.org> References: <89541cda-2c5c-40de-a8ec-8474f825dc15@protonmail.com> <217084C0-1D22-4BD1-B9DF-ADB815B48FE4@FreeBSD.org> Feedback-ID: 21989843:user:proton X-Pm-Message-ID: 4233fbaefa7f266d5f1596c5d16fabdce3d45ce1 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29676, ipnet:109.224.244.0/22, country:GB] X-Rspamd-Queue-Id: 4ZltHG29zQz3c8d X-Spamd-Bar: ---- I updated my source tree and did a whole world build then did the=20 buildworld again without changing anything that would affect something=20 to get rebuild and then the world has been built now in 192 seconds.=20 Indeed, it seems pico files can be cached too. Sorry for the noise and=20 thank you all! Have a good one. On 4/27/25 12:52 PM, Dimitry Andric wrote: > On 27 Apr 2025, at 01:28, Yusuf Yaman wrote: >> I am a new user of 15.0-CURRENT and just updated my source tree and >> noticed that there are now files to be built that have the ".pico" >> extension, as a ccache user, i was enjoying fast world/kernel builds but >> these files doesn't seem to get cached to me and my world builds are >> taking long time than ever. Is there a way to skip building these >> ".pico" files? Thanks in advance and thanks for your efforts and work. >> >> I am on this commit. 6014596899c > We have been using .pico files for years now, so that shouldn't really a > be a problem. At least, I hope not! > > However, if you did an incremental build, previously libllvm and friends > were built from .o files (i.e. position dependent). These were then > added to a static library, with a .a extension. Now libllvm and friends > are built as shared libraries, therefore all the objects have to rebuilt > as position independent (PIC), with a .pico extension. > > Similarly, a number of tools built under usr.bin/clang have been > switched to position independent (PIE), therefore their objects also > have to be rebuilt: instead of .o, these now use .pieo. > > In any case, ccache will still help if you do future rebuilds. It is > only with this particular transition that a number of objects really > have to be fully recompiled. > > -Dimitry > From nobody Sun Apr 27 17:42:44 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Zlv7405WPz5v6yY for ; Sun, 27 Apr 2025 17:42:56 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zlv73379lz3yhn; Sun, 27 Apr 2025 17:42:55 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745775775; 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=X+8PXuO6dc6yO2+6z4SSswXs7SOb+DfO2RAnnuAhvJM=; b=TcN5W0PJQLaCVspxXI2k8hp1aP0uqZ92JLkIznU5EoRaFLhzvNy2291Jju7YfsFWWzNKJ6 +OsevJLVWYwJo3dal6RjWtOMLY1wsYrLcEFQ6lo5rq+Ji23T6jwl21Oj2nsSz49zIfCIZ+ PQ2cRbCXjtKKxwBCrC34d53dWSgmFu1ZEZYuMOCCPq47C3JEVyOEZlEVL02gSoW9nbqm7r zoQZnJdWpzcMJ/AF1SYQ9Vzix8Jng7h8elXmIbOWptkL75JC2baKpxVz/73yF4BKS/BSZ3 9KEHZLIW1yc/cH8FMvRfi+GY9Lza+tAYb4UlQyOkkNDeByA7nAASmyLzRz8uRA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745775775; a=rsa-sha256; cv=none; b=rNTr/QKCZARmEEImW2h/PqHHMGZmW0TQY10WuicO1Pgel6RC2f/o/SxF0wKIYsZIpSt1Vq /fYQqK/AFgITHYbvCGDExF+WgPfG+/SFOrXk0krXxVYi8ukJKgTuQEr6bgpPVv+Xk1aa3n KSpybCkz0HJSgSQP7jd4OQr1NnqJUBBQTML3T0uMyrytG1dJmhSD7miKGruCWYnuWH2i87 qP/p7ZrFQdhcr22Qek+sbJxbt/l33FEUpF3SWNzRFI6eF42k4PelJXfAz6MIFbyJC0yj90 et83OsLCbAIRR56EfxO25cjUeRs3MDJFR/aPoqg3RswfgN2TwHBMjPc+boLgNg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745775775; 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=X+8PXuO6dc6yO2+6z4SSswXs7SOb+DfO2RAnnuAhvJM=; b=kFATgcv7UNsaKoJQyNmf5Kg9QguRQZPFmtjRJwbAAt+Zkilr1lj+NpQ+tAqaBfg4hwvIHM dS/z1if7zPh+ydwQGVYfZN/rNqGvaqk/7iGH7sRLHU+yuMvJU2YP0fAnQS379zKyYBXtuR 5VfPMVz5cXTC43oR/kSWjGJPM4pNjSMXn8gbGHCXKCjj8885TW4BY76AThQr3bAvZnWrpr TIy0puA/xjxkFJb49sliE9MsesSoPwfzd0ZSj4p84AZY3AXnVJ/mD5xP3JZj1fWNh7A/hb kB5vkFBGHSfs7XbCwXotbj5pa8NPJVVAwLNlrMuqGrQID6eanttx9A2ifxDSBA== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R11" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zlv731rnkzNv1; Sun, 27 Apr 2025 17:42:55 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id AFA3041A98; Sun, 27 Apr 2025 19:42:53 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_38A995DF-EB24-406B-80B6-D7EE56000E86"; protocol="application/pgp-signature"; micalg=pgp-sha1 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 \(3731.700.6.1.10\)) Subject: Re: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries From: Dimitry Andric In-Reply-To: Date: Sun, 27 Apr 2025 19:42:44 +0200 Cc: FreeBSD CURRENT Message-Id: <8173C7D9-F95A-4440-82DA-6CF160AAD6C2@FreeBSD.org> References: To: Shawn Webb X-Mailer: Apple Mail (2.3731.700.6.1.10) --Apple-Mail=_38A995DF-EB24-406B-80B6-D7EE56000E86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Apr 2025, at 17:04, Shawn Webb wrote: >=20 > On Sat, Apr 26, 2025 at 06:06:54PM +0200, Dimitry Andric wrote: ... >> Please let me know if you encounter any problems resulting due to = this >> change, as I intend to MFC it. For example, I tried covering all >> incremental build scenarios, but I may have missed some corner case. >=20 > Hey Dimitry, >=20 > I suspect this may be a problem specific to HardenedBSD, but it looks > like cc occasionally crashes. It hits an assert at > /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:2702. >=20 > I can reproduce this by running `env SHELL=3D/bin/sh make buildenv` at > the top of /usr/src. Though, it doesn't reproduce 100%, but perhaps > around 60%. It's asserting on this line: assert(!CCGenDiagnostics && "stdin produces no crash = reproducer"); I think during make buildenv the make framework will run cc --version and ld --version to get at the compiler and linker version, but it could be that it's doing some weird combination that hasn't been thought of. Can you get the exact command line out of the debugger? -Dimitry --Apple-Mail=_38A995DF-EB24-406B-80B6-D7EE56000E86 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCaA5slAAKCRCwXqMKLiCW o2ofAKDAvA8uOEJSOolj6kIgCrsxqHOyIgCfdX+P6sNLe7UZlmr6xtbVpNg59/Y= =u28H -----END PGP SIGNATURE----- --Apple-Mail=_38A995DF-EB24-406B-80B6-D7EE56000E86-- From nobody Sun Apr 27 19:50: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 4Zlxyz3fDkz5vGFj for ; Sun, 27 Apr 2025 19:51:07 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zlxyz2bt8z40YL; Sun, 27 Apr 2025 19:51:07 +0000 (UTC) (envelope-from wulf@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745783467; 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=wUoNeULmcJWTHEdJ/L6bBpgyMPdxfOgri0W022BswIU=; b=DBhBTMHN0YLvuVXnIS+TYgyFMDgDf2f4tjh5LnK18hxdPHA3hDn852fXAxZANGtqInfKPm 6un7AwKGAK1+Zah+QRwOi+Q+bEsBOg85lo/R1QHRwsp9AhwVs2VOrq0/U9xrBpohkntSr7 VkGU2Ekt56xZK6yOLDTsH9sShD3tY0zaGr9RR+6bmmmA4N5Dv9/UIEls+vkYA50dafRZ11 tf2ghRyJIf+nTUVaA300QZsHqpAvTvbjmvo/7nyclmGKvMBS/DGNz1GPu9nNKAJVTpFgJd laf/BTUURBU5klw+LjrKI0POlLacZZxTE3K8tv7JYenrQ/iKBEXqA9VybWN3wQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745783467; a=rsa-sha256; cv=none; b=IJR0pLCUU8K+DIcUQpvyJhjPPlJrXxAFx4NY8fBh9YbLkpBCDyIZ/odK1Ht7kOWDhuUDbP PaUaK0gGrLf6Wnxt+qNrYR6EADoRULDraAMtpH0RbXSo+yDsUDa6zDez/XdC3frVqDk5MZ zQrKWWwD7wnam9lWbLJitTtv0ZNg+v5B2ugJTulp1p2MaqiMDgyH5vB7iEv6JL4rG0eM19 kOyAzJ4WveRBlAGHbI50B7joYXv+gURXOWNIauPSVOm9Xp2R3sIM09dDXz0BsHc1PEzTW5 MrWAXthCCmeHWhTdRQw1FlkCwKybc9RNqthk6U0OQSoi74ODXDw8iJIuKsObXw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745783467; 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=wUoNeULmcJWTHEdJ/L6bBpgyMPdxfOgri0W022BswIU=; b=V0/3v+lp+qRnnNF5BPBoXyihB7JJoECPELOU7QczEG4ERkQ90et3+fWtUz2epuFvsSpjoC iNPa7n2r6gSQcttV9gtDbxTdheetwW9OgMLyX28fD6yRfrTZGzK5ob8qULDgt0e9qBSRur WeOOnm44TtXFOj6aZSgN8iqsAAh3WNZgkRt6oCNwPhLurQdYeoyDLVP23DXC68khctrfeu SyTdTScJSwDgtBK7VbwoCNYdJ0cSEzui7dd17jfsVw1VQgz3fC27W+NTvQDrJtRXKic9ID WnlorrXfRznzrfv9mAIU8ZOyhj5N2yfbJGR8kN9dj3N0j2Muexa6TyGVF0x0OQ== Received: from [192.168.0.30] (unknown [176.120.234.130]) (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: wulf) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zlxyy5SV5zQ4N; Sun, 27 Apr 2025 19:51:06 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Message-ID: <0f29a3cf-813e-44a5-8769-2685fe2344b4@FreeBSD.org> Date: Sun, 27 Apr 2025 22:50:56 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: April 2025 stabilization week To: Gleb Smirnoff , Dave Cottlehuber Cc: freebsd-current References: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> <4aad4a70-a953-458b-ac37-675b6901f28c@app.fastmail.com> <7c4e115c-f0a5-4462-a34f-38291770aa92@FreeBSD.org> Content-Language: en-US From: Vladimir Kondratyev In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/27/25 19:57, Gleb Smirnoff wrote: > On Sun, Apr 27, 2025 at 03:38:46PM +0000, Dave Cottlehuber wrote: > D> On Sat, 26 Apr 2025, at 16:19, Vladimir Kondratyev wrote: > D> > On 4/24/25 21:46, Gleb Smirnoff wrote: > D> >> On Thu, Apr 24, 2025 at 05:48:46PM +0000, Dave Cottlehuber wrote: > D> >> D> On Thu, 24 Apr 2025, at 17:31, Gleb Smirnoff wrote: > D> >> D> > D> This issue actually came up last month but I had no time to > D> >> D> > investigate > D> >> D> > D> then, details > D> >> D> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286045 > D> >> D> > > D> >> D> > Is this regression since last stabweek or from an earlier point? > D> >> D> > D> >> D> Just since March stabweek. > D> >> > D> >> There were no changes to the driver :( > D> >> > D> >> Any chance you can make a bisect? > D> >> > D> > > D> > I think it is regression from daa098cc37b9 > > Great that the problem has been solved, but there is still an inconsistency. > Dave says this was a regression since March stabweek. But the daa098cc37b9 was > already there. > I see 3 possible reasons: 1. Pre-daa098cc37b9 system running during March stabweek. 2. Different touchpad hardware. 3. Something else. E.g. a luck. -- WBR Vladimir Kondratyev From nobody Sun Apr 27 21:40:33 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 4Zm0Pj4vCjz5vMXG for ; Sun, 27 Apr 2025 21:40:57 +0000 (UTC) (envelope-from dch@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zm0Pj4LHHz3H8c; Sun, 27 Apr 2025 21:40:57 +0000 (UTC) (envelope-from dch@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745790057; 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=4zcGflhJwmdSUMPmM20p07mOHkukPEe3D2LTLyCS5Dw=; b=VrpXi8/m5Yg5FUcRzrK4+muTnxxCBmJEOgZ1jZTikEbSQDXZ7c3iMuhwWLYIUQUrFp+iB2 QhkUUz02lY71tg7YX0ORRTiAFDj8mOWayiAGIe+L8/d7tY4e8fvoovbH6VjT7WRh+XbfSc 7zm0UjzClGqq52eg3AH2Rt8V5PDHmV8WQc3b+njxYXOC0ENE9q2Vq/KpayXwJvuTQSf0aZ 60gbDKr2+RF+nW3yQlkxhdMtjsF/JqjoOS6xBCMpPto/T/JuYzL6ZJJXqpaFTcv+idWzZz GbeMMh5H9SlgFvUhZYmB0vj9shvYyAAZ7hemIVq7wmM5vtn80kFeL/fRwrW17Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745790057; a=rsa-sha256; cv=none; b=V3eDSAgW7Kli5mfQ36btrlEW5GrTZmsgARHL79SiNd5ual3suOV4uZ8oJoipjuBsi7cHoL jawNMlctr2ULsdp5psxt5rQwWEAFoBaqUS9aozAJvw9KoDaACjLTlRNi4dyezh6Rr8QKiM LMfwi+wjpyMGWfcx7DbvoDrVE3yASbaogad55T/OzostySqybOFWevJ7MtZL/wEBozzVjM BStCR//+g+SxklCV3mNY8Nr1c3SQVIjfl394PVxDa/JdaKHG83naXVBCvlgUH3Ab4u6VBC Ut+/mkeorxsVgA0X+oo7dfchfEXe6O/QPe2X7Ps1NyW5BfT7zvR6Gk4WlnDX5Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745790057; 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=4zcGflhJwmdSUMPmM20p07mOHkukPEe3D2LTLyCS5Dw=; b=XxmkAAT9Tze0nENJhv2PIYa7oVBOK7j8ckGvIf/tJDnm/q1UItMslicndPj4eFgdeGfUdq rc+EMOAphS/j7cNk5hEa5pJ15WQMLRzHPuZ78TU8AYsGv6aWBPB9ohXsZlKn4dlsDwhb7O wK6DX6mKXZMG/7sl/u4we4vaeja92Ct1k+0PquqEJriduqsrSnYWnMiMmJlfpLOaxThN8k iteQT1kXOzg5Hatyd0iYtiWzXhiXJooMDwzZdTfossB+FM2U7I/wKcJ3HfohCoD9umlknI jo/eEalr5dNRZ89teKEjXgPDXZOsm25xFSKwHOtCHBpRBCbWWlPVB4MUFuix/Q== Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com [103.168.172.200]) (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: dch/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Zm0Pj3nWGzkg7; Sun, 27 Apr 2025 21:40:57 +0000 (UTC) (envelope-from dch@freebsd.org) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfauth.phl.internal (Postfix) with ESMTP id 0F3701200043; Sun, 27 Apr 2025 17:40:54 -0400 (EDT) Received: from phl-imap-16 ([10.202.2.88]) by phl-compute-02.internal (MEProxy); Sun, 27 Apr 2025 17:40:54 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvheeludejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefogg ffhffvvefkjghfufgtgfesthhqredtredtjeenucfhrhhomhepfdffrghvvgcuvehothht lhgvhhhusggvrhdfuceouggthhesfhhrvggvsghsugdrohhrgheqnecuggftrfgrthhtvg hrnheplefgledvffffgeekjedvteekiefftdfggfeutedthffhteefkeeljedtveeugffg necuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegutghhodhmvghsmhhtphgruhhthhhpvghrshho nhgrlhhithihqdduvdegledutdefgeduqdduvddufeduudejjedquggthheppehfrhgvvg gsshgurdhorhhgsehfrghsthhmrghilhdrfhhmpdhnsggprhgtphhtthhopeefpdhmohgu vgepshhmthhpohhuthdprhgtphhtthhopehfrhgvvggsshguqdgtuhhrrhgvnhhtsehfrh gvvggsshgurdhorhhgpdhrtghpthhtohepghhlvggsihhushesfhhrvggvsghsugdrohhr ghdprhgtphhtthhopeifuhhlfhesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: icedc46df:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id DD5712CC006E; Sun, 27 Apr 2025 17:40:53 -0400 (EDT) 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: T7d8fb190958b0cc3 Date: Sun, 27 Apr 2025 21:40:33 +0000 From: "Dave Cottlehuber" To: "Vladimir Kondratyev" , "Gleb Smirnoff" Cc: freebsd-current Message-Id: <6c93a06d-0ba2-4951-810d-a658cdfd82bf@app.fastmail.com> In-Reply-To: <0f29a3cf-813e-44a5-8769-2685fe2344b4@FreeBSD.org> References: <447332f8-a8bc-4b90-a605-4c705a58f491@app.fastmail.com> <4aad4a70-a953-458b-ac37-675b6901f28c@app.fastmail.com> <7c4e115c-f0a5-4462-a34f-38291770aa92@FreeBSD.org> <0f29a3cf-813e-44a5-8769-2685fe2344b4@FreeBSD.org> Subject: Re: April 2025 stabilization week Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, 27 Apr 2025, at 19:50, Vladimir Kondratyev wrote: > On 4/27/25 19:57, Gleb Smirnoff wrote: > I see 3 possible reasons: > > 1. Pre-daa098cc37b9 system running during March stabweek. > 2. Different touchpad hardware. > 3. Something else. E.g. a luck. > > --=20 > WBR > Vladimir Kondratyev This is just my poor choice of English, my native language. Mea Culpa. I can see from my panic that bug was at least present for me on Apr 9. The bug has been present, for me, since I upgraded on the stab week, I did not have it in the preceding stab month, February. I missed reporting it during March stabweek, which was 24 March: https://github.com/glebius/FreeBSD/releases/tag/main-stabweek-2025-Mar and daa098cc37b9db36281623c00558976aea4fa90e was committed March 7. because my laptop space is small I don't have more BE to check, but timeline looks correct to me. A+ Dave =E2=80=94=E2=80=94=E2=80=94 O for a muse of fire, that would ascend the brightest heaven of inventio= n!